tags:

views:

38

answers:

2

Is there more work, or source code files required to customize your look and feel (skins)? How maintainable and readable is Spark relative to Halo? Is it more productive and easier to customize overall than Halo, about the same, less?

If you're an SDK user who was 99% happy with Halo's appearance (maybe just a few CSS tweaks), is switching to Spark creating more work for you? Do we now need to employ designers to get a reasonably complete look and feel?

A: 

IMHO you have more possibilities with Spark skins. Therefore it requires in some cases more work but because of that the skins are maintainable, depending on the developer as well of course. I haven't modified Halo skins, so I started working with skins with Spark. I'm not the skin expert and there are just a few skins I worked on. The difficulty was ok. Creating new skins seems to be hard but to extend an existing skin is quite easy.

If you're (99%) happy and you don't see the advantage of switching to Spark, then you should'nt do it.

Some things changed while using Spark components e.g. the possibility to use an icon in a Button control dosn't exist in a Spark Button. Of course you can write your own skin and have more possibilities to do that, but this takes time. Except the Button, I don't regret that we switched to Spark.

hering
If Adobe didn't seem to be pushing so hard for us NOT to use Halo, I think I'd be comfortable with that. But since they say in the actual docs that we "shouldn't use such and such" Halo components and should use the Spark ones instead, it's worrisome. It also seems like support for Halo in FB has become an afterthought (I can't get design mode to display a Halo style, even with Halo selected as the theme), so Adobe's making it difficult just to continue using it. Personally I don't see why we can't have two parallel component sets since Halo's design **may** work better in some use-cases.
Crusader
Actually the wording Adobe authoritatively uses (say if you're going to use "Canvas") is "use spark.components.BorderContainer instead". Well what if we don't want to? They haven't explained **why** we should use Spark instead, and due to it's "half complete" status now with tons of missing components, I don't really like the idea of almost guaranteeing maintenance work and updates needed to my code once SDK 5 comes out. On the other hand if we just use Halo permanently (assuming Adobe isn't going to pull the rug from it later, who knows), the code is "done" the first time. Frustrating.
Crusader
+1  A: 

Having done quite a bit of skinning with both halo and spark, I can say I find spark to be much more flexible (no pun intended). With halo, I used to spend a lot of time writing ActionScript to draw programmatic skins. Flex 4 introduced the new states model and FXG, which allows you to create your skins with MXML. Less code, more readable, much more maintainable in my experience. The separation of form and function is also much more clean with spark. It took my a good amount of time to really get my head around the spark way of doing things, but in the end it was worth the effort. On the downside, I'm finding the spark control set to be incomplete (no Tree, DataGrid, DividedBox, DatePicker, ColorPicker, icon Button, to name a few), and the new spark controls have their quirks (why doesn't the DropDownList size itself to its content like its halo counterpart?!), but overall I'm happy.

Wade Mueller
I definitely wouldn't doubt that Spark is more flexible since it was one of the goals, but if you're someone who just doesn't care or need to do 'quite a bit of skinning', would you say it's still an improvement over Halo? I'm finding that in order to get something better than the plain looking-spark skin (which Halo gave you by default with no work), that I actually have to do more work than I did previously. Perhaps I'm over-estimating how much can be done in Spark via pure CSS?
Crusader