I'll add my 2 cents here.  A lot of good points either way you look at
it in this thread.

I'd argue that what draws people to ASP.NET is not the components.  It
is the speed in which you can click out a web application in VS.NET. 
[sidetrack] I hear a lot of people rant and rave about VB.NET because
of how fast you can build GUI's.  Well, it's not VB the language that
makes that possible.  It's VS.NET. [/sidetrack].

So I think the component argument should be aimed at JSF, Wicket, etc
because in all honestly I don't believe Tapestry is competing against
.NET.

I personally like Tapestry.  And I am all for change as long as it is
for the better.  Don't take one step foward and 2 steps back just to
make the framework *cooler*.

My biggest complaint about Tapestry 4.0, or whatever it will be
called, is that it is integrated with HiveMind.  These are 2 different
project solving 2 different problems.  I don't think an IoC container
should be in the same distribution as a Web App Framework.  With that
being said, I don't know how Howard is planning on using them
together.  I haven't had a chance to look at any of the new Tapestry
stuff yet.

I am hoping that IoC still remains a developers option when using
Tapestry.  How hard will it be to use Spring instead of HiveMind if I
want?  Is that even possible?

BTW - I've taken a look at Wicket and while it does look like a
Tapestry clone, it is coming along quite nicely.  If I am forced to
use HiveMind with the new Tapestry, I'll use Wicket. :)

Gregg Bolinger



On 5/6/05, Karthik Abram <[EMAIL PROTECTED]> wrote:
> 
> I've not seen one blog/article/email that convinces me HiveMind provides any
> capabilities to the component writer. I believe there are changes being made
> to simplify writing components a bit, but still, they don't require
> HiveMind. HiveMind will also hamper the adoption of Tapestry to some extent.
> Corporations now have to accept another OSS into their support structure. If
> a HiveMind like framework is required, then why no Spring which is clearly
> more popular?
> 
> I agree with Patrick - there are lots of features (e.g. rewind cycle) that
> can be worked on. The documentation - which is outdated (including the book)
> can be brought up-to-speed. The famed Tapestry learning curve can be
> addressed with good examples ...
> 
> In the end, OSS is also a player in the free market. I think it is telling
> that Tapestry is technically a better framework, but has so small a
> marketshare. Not the first time I've seen this.
> 
> -----Original Message-----
> From: Brian K. Wallace [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 06, 2005 3:01 AM
> To: Tapestry users
> Subject: Re: Components to fry JSF and all other frameworks
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> While I understand the sentiment you present below, I must disagree.
> You, as a user, *should* have the loudest vote. Not that all of every
> user's wants and desires will ever be filled, but the users are the
> community. If you want something, speak up. If you get a lot of other
> users saying it's a bad idea - well, whether it is or not it probably
> won't get voted to the top of the heap of changes. Still doesn't mean it
> can't end up in the codebase, just means you'd probably have to be the
> one to step outside the 'user' role and implement it. In emphasizing
> 'should' above I acknowledge that there is usually a guiding direction
> (usually being more often than not in an ideal world) that may either
> eliminate or modify the needs or wants presented in a current version.
> However I do not believe that the Tapestry community is just the core
> that brought it into Apache and under Jakarta. There is still a sense of
> directing everything toward Howard for 'approval', but I see this as
> more of a case of him providing an overall direction and no real
> objections presented to that direction. In the early days I did not
> quite feel that (it was Howard's baby and he knew it better than
> anyone), but as the community has grown and more people are utilizing
> *JIRA* (note: Jira is not just for bugs) and taking Tapestry outside the
> box in which it had previously been implemented it appears as though
> more and more the users are powering the development. If not powering,
> at least empowering. (please disregard any words that appear marketing
> in nature ;-))
> 
> All that said, yes - the committers do have the only votes that _really_
> count - as in "binding". However, I have yet to see a -1 from anyone
> participating in a vote - binding or not - be ignored. You want the
> kitchen sink before you'll change your -1? Alright - you'd probably be
> vetoed. But the key to this, and any other project, is the path forward.
> And all the committers, while having their own views (which may or may
> not match anyone else's - not even Howard's), have shown their
> willingness to discuss changes.
> 
> As to the Hivemind dependency being an 'added' layer - if you look at
> the core of what Tapestry requires, both pre and post Hivemind change,
> you'll see that there are no truly new requirements of users. You can
> still do what you've been doing and achieve the same results.
> Refactoring the code to separate more of what Hivemind does best into
> the Hivemind codebase and pointing Tapestry to use it doesn't add a
> whole lot more to what Tapestry requires and does add a whole lot more
> to what Tapestry can provide. If I write no log statements, I still
> depend on logging. If I use no Hivemind integration in Tapestry, I still
> depend on it. Same concept. If it makes it so developers (not speaking
> of commiters here) can more easily create the cool components - I'm all
> for it. And if it makes it easier for developers (speaking Tapestry
> developers here) to stay flexible in the future direction of Tapestry -
> I'm all for that as well.
> 
> My .02
> 
> Patrick Casey wrote:
> |       Of course I'm not a tapestry dev; I'm a user, so what I *want* to
> | happen may not match what the community as a whole wants to happen.
> | Likewise, the devs are the only vote that really counts :).
> |
> |       --- Pat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> 
> iD8DBQFCexYSaCoPKRow/gARAjKQAKChIC9rOTZ1APmhpBg1rdGC/FCMxwCgri9z
> 4PToslltH7nku5yMm7rek4k=
> =0Hbg
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to