Swiz vs. Spicefactory's Parsley framework

[sbavince]

The open source project Parsley seems to pursue the same goal as Swiz.
http://www.spicefactory.org/parsley/

Since both are open source projects, I am sure the Swiz team evaluated
why they don't want to put their energy into evolving the existing and
mature (version 2.0) Parsley, but instead starting a new project.

Can somebody remember us what those reasons were. Reinventing the
wheel normally doesn't make sense between open source projects, so
there must have been strong reasons what the Swiz team wants to do
radically differently so they decided to start the new project.

I think it would be nice for the (potential) users to know this
"mission statement".

[Chris Scott]

Some loaded and good question! OK, so version numbers are not everything! . I have stuck with a pre-1.0 numbering because I intend the 1.0 release to be a highly professional production release. Parsley seems to have release a 1.0 shortly followed by a 2.0 (I am getting this from their Jira site). I would not get fooled by version numbers, they don't meen a thing. We have in fact had 6 releases. Parsley has had 2.

As far as why I didn't approach parsley when starting Swiz, Parsley 1.0 was released in April of this year, and 2.0 in June. I began development of Swiz in January of 2008 and posted my first release in June 2008 and have only become aware of Parsley very recently.

To my knowledge, the creator of Parsley knows Sönke quiet well, and knows quiet a bit about Swiz. I would post the same question to the Parsley list of reinventing the wheel instead of joining my project to make it the best IoC and MVC framework for Flex. But if we are going to have strong competition in this space, it will make Swiz even better. There are many significantly large apps out there built with Swiz, it's a rubust framework.

I hope that helps to clear up any confusion.
-chris

[Ben Clinkinbeard]

Just as another example that version numbers mean nothing, flexlib
(http://code.google.com/p/flexlib/) is almost certainly the most
widely used OSS Flex project in existence, and the most recent version
number is .2.4. Not 2.4, 0.2.4. So, version number really says nothing
and is completely dependent on the authors' preference.

Ben


On Jul 2, 1:37 am, sbavince <vincent.spal...@gmail.com> wrote:
> The open source project Parsley seems to pursue the same goal as Swiz.http://www.spicefactory.org/parsley/

[Peter Bell]

I wouldn't let the release numbering fool you - swiz is a pretty
mature framework and has been out there for quite a while now. Parsley
on the other hand, well, I though I did a decent job of keeping up
with most of the major flex frameworks, but personally I've never
heard of it. I'd ask more about the team behind it and adoption, but I
think that's a little off topic for a mailing list about swiz. As for
the "mission statement" of swiz, I think the summary here is pretty
clear: http://code.google.com/p/swizframework/

I do suggest you check out a copy of swiz. It's got a great team
behind it and if anyone on the parsley team would like to help out
with the project I'm sure Chris et al would appreciate some more hands.

Best Wishes,
Peter

[Brian Kotek]

Until your email, I had never even heard of this, and I like to think I stay fairly current on what's going on. Have these folks ever presented about the framework at a major conference?

The JIRA site only goes back to 1.1, but that was only released in January, with 2.0 in June. Swiz has been in development for far longer than that. And yes, version numbers really mean nothing, if every release was a new version, Swiz would be at version 6.

A Google search shows over twice as many results for Swiz as it does for Parsley. Not that that is very definitive data, but it indicates a general trend.

I'm not badmouthing their project, I've never heard anything about it. But I know Chris personally and he is one of the smartest people I have ever met. Which means, at least to me, the Parsley folks would have to be doing something *really* impressive for me to think it is somehow superior. That's my own personal opinion of course, but it surely plays into the decision.

Regards,

Brian

[sitron]

just to rectify a few things:
- parsley has been around for a while (1.0 version in march 08,
http://www.spicefactory.org/news/news-2008-03-11.php)
- the guy behind it is somehow related to PowerFlasher (cpny which
created FDT)
i think it might be interesting to get a look at their work...

a happy swiz user

[Tom Sugden]

I agree that the competition is a good thing for Flex frameworks in
general, but if we developers do sometimes have a tendancy to prefer
building our own frameworks to learning others! I can give a little
more background on Parsley:

Parsley has been around in one form or another for several years and
is certainly being used on enterprise Flex projects. Although there
have been 2 major releases, there have been incremental releases in
between. Version 1 was a Spring-like IoC container and MVC framework,
similar to Prana/Spring ActionScript with a Cairngorm-like Front
Controller, but Version 2 is a complete rewrite and a major leap
forward. As well as a fully featured IoC container, it contains a
loosely-coupled messaging framework and tight integration with Flex
modules and the Flex logging framework. Not to mention the
complementary Spicelib library, with its reflection and task
processing APIs. Check out the Getting Started section of the
developer manual for details:

http://www.spicefactory.org/parsley/docs/2.0/manual/

I might describe Parsley as the framework developer's framework.
Having worked on framework code myself, I've been most impressed by
the design and engineering of Parsley. There is a complete separation
between the configuration mechanism and the IoC container itself,
which allows for great flexibility. Swiz or Flicc style MXML and
metadata can be used instead of or together with external XML files,
ActionScript or Parsley's own MXML tags as appropriate. There are
different cases where each is beneficial. The design also shows a
careful application of design patterns that makes it easy to
customize. For example, by writing a single object definition
decorator, I can begin to annotate my objects with a new metadata tag
and the new configuration can also be applied in MXML or XML.

Swiz is the lighterweight framework, but Parsley is more feature rich
and extensible with a good developer manual. Like Swiz, Parsley
"imposes no JEE patterns on your code, no repetitive folder layouts,
and no boilerplate code on your development". It also "represents best
practices learned from the top RIA developers at some of the best
consulting firms in the industry"! ;-)

Should there be a move to consolidate frameworks or is it too much fun
building them separately?

Best,
Tom

[Dennis]

Have any swiz users actualy tried the parsley framework? I am reading
the manual and it sounds quite interesting.

Dennis

[Tom Sugden]

Hi Dennis, etc,

Earlier this year I evaluated Swiz, Flicc, Spring ActionScript and
Parsley. I opted for Parsley because of its support for modular
development, its comprehensive feature set, and its documentation and
unit tests. We tend to work on modular projects that sometimes have
many developers with different levels of experience. However, I've
also used and enjoyed using Swiz and Flicc, but have never tried
Spring ActionScript in anger, although it seems to be similar to
Parsley 1.

Parsley 2 has certainly learned some lessons from Swiz, and I think
there are lessons that Swiz could learn from Parsley. It's probably
not appropriate to consolidate the two since their aspirations are
different. Parsley intends to be a fully-fledged application framework
for building modular Flex projects, while Swiz distinguishes itself by
being especially lightweight.

I think Parsley currently has the better design. It can be used in a
manner that is even simpler than Swiz, imposing less dependency on the
library itself into your application code. This is because Parsley
uses an mx:Object instead of a BeanLoader, and uses a normal
EventDispatcher together with metadata instead of the static methods
that Swiz uses for global event dispatching and listening. The
approach to view wiring is also subtly different. In Parsley, you
dispatch a bubbling event to instruct Parsley to begin "managing" that
view. The view then enters an IoC context and can partake in any of
the features of Parsley, such as lifecycle methods, message handling
and interception, etc.

The above is intended as constructive feedback, since I do think that Swiz
has really spurred on the other frameworks and I look forward to
watching it evolve.

Best,
Tom

[Moritz @home]

Thanks Tom...

finally some constructive information ;)

The module bit sounds really interessting to us... Exactly that was our big concern with Swiz. Learning more about alternatives is a good thing, particularly if you stuck since 3 months in a framework without any docs or example apps regarding modular application design.

[Sönke Rohde]

Hi,

On 03.07.2009, at 13:31, Tom Sugden wrote:

>
> Hi Dennis, etc,
> [...]

>
> I think Parsley currently has the better design. It can be used in a
> manner that is even simpler than Swiz, imposing less dependency on the
> library itself into your application code. This is because Parsley
> uses an mx:Object instead of a BeanLoader, and uses a normal
> EventDispatcher together with metadata instead of the static methods
> that Swiz uses for global event dispatching and listening. The
> approach to view wiring is also subtly different. In Parsley, you
> dispatch a bubbling event to instruct Parsley to begin "managing" that
> view. The view then enters an IoC context and can partake in any of
> the features of Parsley, such as lifecycle methods, message handling
> and interception, etc.
>

Swiz also supports bubbling events since the 0.6 release.
Already part of SVN but not released yet is the new IDispatcherBean
interface.
When for instance your controller implements that interface you have
to implement a setter for a dispatcher:IEventDispatcher which can be
used to dispatch events right from this instance instead of
Swiz.dispatchEvent. Also the BeanLoader contains a protected member of
the dispatcher so you could set it already within the BeanLoader
declarations.

Cheers,
Sönke

[...]

[Sönke Rohde]

There are very good examples projects available for Swiz!

Ben has made a wonderful example using the presentation model: http://www.returnundefined.com/2009/05/swiz-example-application-with-presentation-model-pattern
Brian has a 5 blog posts series: http://www.briankotek.com/blog/index.cfm/2009/1/8/Using-Swiz-Part-1-Initial-Setup
Christophe Coenraets (Adobe Evangelist): http://coenraets.org/blog/2009/02/sample-application-using-the-swiz-framework-and-blazeds/

And I have a few blog posts up with lots of explanations and code
snippeds: http://soenkerohde.com/category/swiz/

btw: The module thing is the next big story in our backlog and from
what Chris told me so far it will be damn flexible.

to the docs: you have read Chris mail yesterday, so ...

Cheers,
Sönke

[Tom Sugden]

> Swiz also supports bubbling events since the 0.6 release.

Please could you clarify? Do you mean that view injection can be
instructed through a bubbling event, rather than happening on all
display objects added to stage that pass through the filters?

> Already part of SVN but not released yet is the new IDispatcherBean
> interface.
> When for instance your controller implements that interface you have
> to implement a setter for a dispatcher:IEventDispatcher which can be
> used to dispatch events right from this instance instead of
> Swiz.dispatchEvent. Also the BeanLoader contains a protected member of
> the dispatcher so you could set it already within the BeanLoader
> declarations.

Parsley takes a slightly different approach, using metadata rather
than interfaces.

First you annotate your event dispatching class as follows:

---
[Event(name="myEvent", type="my.events.MyEvent")]
[ManagedEvents(names="myEvent")]
public class MyClass extends EventDispatcher
{
---

The second metadata tag tells Parsley that the event should enter the
messaging framework.

Then wherever you want to receive the message, you annotate the method
like this:

---
[MessageHandler(selector="myEvent")]
public function handleMyEvent( event : Event ) : void
{
---

Parsley will then wire them up. There are some more elaborate features
too, like message bindings, filtering by event class and interception.



>
> Cheers,
> Sönke
>
> [...]
> >
>

[Chris Scott]

Tom,

What is your purpose in this list? To my knowledge, we don't have Swiz
users on the Parsley list telling people why Swiz is the better with
inaccurate information. I find it a bit offensive.

-Chris

Sent from my iPhone

[Tom Sugden]

Chris,

Sorry for causing offence, Chris. That wasn't my intention. I have a
broad interest in frameworks and have been watching the development of
Swiz amongst others. This thread was a comparison between the two
frameworks, so I thought it would be interesting to explain a little
about the design of Parsley, in case it influences your own work.
Please excuse me.

[Borek]

Tom,

I for one was highly enjoying your insight into Parsley even though I
am a pretty happy Swiz user (and don't know Parsley at all). It
surprises me that Chris should take offense from this - your
contribution has been very informative and un-biased in my opinion.

Borek

On Jul 3, 4:00 pm, Tom Sugden <tom.sug...@gmail.com> wrote:
> Chris,
>
> Sorry for causing offence, Chris. That wasn't my intention. I have a
> broad interest in frameworks and have been watching the development of
> Swiz amongst others. This thread was a comparison between the two
> frameworks, so I thought it would be interesting to explain a little
> about the design of Parsley, in case it influences your own work.
> Please excuse me.
>
> Best,
> Tom
>

> On Fri, Jul 3, 2009 at 2:40 PM, Chris Scott<chris.scott....@gmail.com> wrote:
>
> > Tom,
>
> > What is your purpose in this list? To my knowledge, we don't have Swiz
> > users on the Parsley list telling people why Swiz is the better with
> > inaccurate information. I find it a bit offensive.
>
> > -Chris
>
> > Sent from my iPhone
>

> >> On Fri, Jul 3, 2009 at 9:05 AM, Dennis<dennis.croit...@gmail.com>

[sbavince]

To come back to my original question, my conclusion so far:

- Swiz's USP is lightweightness.
- Swiz is better advertised/known in the community.
- Are there more?

What I also seem to read from the posts: Parsley seems to be an old
project - that's also what I thought, if you read my initial/
initiating question. But, unfortunately, it wasn't made public/open
source until a year ago, so the teams probably didn't know about each
other.

[maxim.porges]

@sbavince,

Your original question was focused on why the decision was made to
build Swiz instead of contribute to Parsley. I was paying a little
attention to the Flex IOC space at the time so I'll post my
recollection, and Chris can correct me if need be.

In late 2007/early 2008, the state of affairs for IoC frameworks for
Flex was pretty poor. There were a few projects in existence, but I
think Prana was the furthest along at the time; when I downloaded the
sample app I couldn't get it to work (probably user error, but there
it is). Prana was focused on pure-AS3 support configured with XML,
which made no sense to me since the MXML support in Flex gives you an
instant XML-to-object mapping, and I only do Flex development so I
didn't care for XML-based config. Since there was nothing in the Flex
IOC space that followed this approach, I started tinkering with an IOC
container based on MXML some time in early 2008.

Chris and I both appeared on a podcast on CFWeekly in April 2008, at
which time I learned that Chris had come up with the same idea already
and was much further along with Swiz than I was with my IOC
implementation. During discussion, it turned out that Chris had come
to similar conclusions with regard to the need for a really
lightweight Flex-based IOC container. Chris demo'd Swiz at cf.objective
() that year, and the rest is history. Swiz worked at cf.objective()
(Chris gave me a copy of the alpha, which I put in to an app on the
flight home from the conference), and has been production-ready since
shortly after the cf.objective() demo when Chris did some internal
tuning for a public release.

Obviously, Prana's now Spring-AS, Swiz continues to add features and
robustness, and there are other options (apparently like Parsley,
which I also had not heard of) on the scene. What I personally like
about Swiz is that there is just enough in it to make it work, and
then I can go back to writing code - the same things I like about
Spring, which was Swiz's inspiration. I haven't looked at the other
IOC libraries because I haven't needed to yet.

As for the feature comparison, my experience with framework debates is
that on a long enough timeline you're left with a handful of the most
popular options with a near-identical feature set. In the end, the
only real draw factor for any of them comes down to personal
preference in implementation or proliferation of legacy
implementations.

- max

[santiago]

there's so little documentation of swiz,hope you guys do a better
job.

[Brian Kotek]

What would you like to see? We know that the existing doc pages are short, but they do clearly explain most of the key features. The whole point of Swiz is that it is extremely simple, which means even the updated documentation is probably going to be fairly short. There's not much to explain, since Swiz is so unintrusive.

2009/7/25 santiago <vaque...@gmail.com>

[Cliff Meyers]

One item I think could be valuable to add to the docs is a single
document that gives a crash course in Swiz. The existing doc pages
are pretty detailed and actually a bit much to slog through for a
first timer. What I think noobs would like to see is how in 5-10
minutes they can build a simple view, dispatch events, mediate them,
invoke a service and bind result data back to the View.

Also useful would be a discussion of pro/cons of injecting Controllers
into Views versus injecting Controller *properties* into Views.

-Cliff

[Rush]

I guess I found the documentation lacking as well, so I generated the
ASDocs. The new swizframework.org is good as well.
I'm not sure if that helps anyone, but...
Here they are http://www.on3solutions.com/swiz062

Of course the code needs a little more documentation in it, but this
gives a clear picture of the framework.

Rob

On Jul 25, 3:11 pm, Brian Kotek <brian...@gmail.com> wrote:
> What would you like to see? We know that the existing doc pages are short,
> but they do clearly explain most of the key features. The whole point of
> Swiz is that it is extremely simple, which means even the updated
> documentation is probably going to be fairly short. There's not much to
> explain, since Swiz is so unintrusive.
>

> 2009/7/25 santiago <vaquero...@gmail.com>

[Rush]

I generated the ASDocs and posted them at http://www.on3solutions.com/swiz062.

On Jul 25, 3:11 pm, Brian Kotek <brian...@gmail.com> wrote:

> What would you like to see? We know that the existing doc pages are short,
> but they do clearly explain most of the key features. The whole point of
> Swiz is that it is extremely simple, which means even the updated
> documentation is probably going to be fairly short. There's not much to
> explain, since Swiz is so unintrusive.
>

> 2009/7/25 santiago <vaquero...@gmail.com>

[loxy]

Besides, the docu of Parsley is much better than Swiz...

[Ben Clinkinbeard]

Hey Cliff,

That will definitely be getting created. I am voting to call it The
Idiots Guide to Teach Yourself Swiz in 15 minutes for Dummies, but I
may get outvoted on that aspect. Either way, there will be a
quickstart that contains exactly the type of info you described.

Ben

On Jul 27, 6:49 pm, Cliff Meyers <cliff.mey...@gmail.com> wrote:
> One item I think could be valuable to add to the docs is a single
> document that gives a crash course in Swiz.  The existing doc pages
> are pretty detailed and actually a bit much to slog through for a
> first timer.  What I think noobs would like to see is how in 5-10
> minutes they can build a simple view, dispatch events, mediate them,
> invoke a service and bind result data back to the View.
>
> Also useful would be a discussion of pro/cons of injecting Controllers
> into Views versus injecting Controller *properties* into Views.
>
> -Cliff
>

> On Sat, Jul 25, 2009 at 2:11 PM, Brian Kotek<brian...@gmail.com> wrote:
> > What would you like to see? We know that the existing doc pages are short,
> > but they do clearly explain most of the key features. The whole point of
> > Swiz is that it is extremely simple, which means even the updated
> > documentation is probably going to be fairly short. There's not much to
> > explain, since Swiz is so unintrusive.
>

> > 2009/7/25 santiago <vaquero...@gmail.com>