This is something that's bothered our dev team since we took up Tapestry.
It seems that the Tapestry philosophy is to have a static web page. But
what about forms that require dynamicly displayed fields (see my other
posts from today). Or what about i18n....you may need to change the
layout of your web page based on the language selected. It would be
really nice to have some kind of layout manager to dynamically alter the
layout of the page. Having multiple pages, each with it's own layout, is
heavy a solution and presents ugly maintenance issues.
Would it really be that hard for Tapestry to include layout managers &
dynamic components? Sure, it would take time, but it just doesn't seem
like rocket science.
As far as people using them, our dev team would be on such features like
white on rice. Dynamic forms and i18n are at the heart of many of our
apps. I would have to believe that many other enterprise web apps have
similar requirements.
- Mike
"Patrick Casey" <[EMAIL PROTECTED]>
01/27/2006 10:28 AM
Please respond to
"Tapestry users" <tapestry-user@jakarta.apache.org>
To
"'Tapestry users'" <tapestry-user@jakarta.apache.org>
cc
Subject
RE: tapestry not really component based?
I don't necessarily buy the slippery slope argument here.
One might
as well argue "well if we put listener functions in the page class that
fire
when users click links or buttons, the before you know it users are going
to
insist on the full swing set, so we shouldn't do listener functions".
Additionally, I have to point out that, if the users *do*
want the
full swing set (which I don't think they do; I know I don't, but it's a
hypothetical), then why not give it to them, or at least as much as is
practical?
Ultimately Howard's not doing this to satisfy his own
desire for
theoretical perfection; he wants people to actually *use* the thing. If
making it usable to the "average" programmer, if such a thing actually
exists, means making compromises with architectural purity, then so be it.
In any event, I've long since found workarounds for the
whole "java
code can't create a component" thing, so this isn't near the top of my
personal wish list. I do remember back though when I hadn't yet
implemented
those workarounds when it did, indeed, bother me.
Perhaps those of us who know the framework relatively
well need to
try to see things from the perspective of those who don't. Stuff which is
second nature to us isn't to a newbie and, if this framework is to grow,
it
has to be obvious not only to the old hands, but *also* to the newbies.
So if a large percentage of the new users find something
confusing/awkward/weird, I think it is worth discussing, even if the more
experience tapestry staff think's it's second nature.
--- Pat
> -----Original Message-----
> From: Cliff Zhao [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 27, 2006 10:13 AM
> To: Tapestry users
> Subject: Re: tapestry not really component based?
>
> IMO, this is not about one dynamic component. If you open the door to
> introduce the dynamically created component, you introduce a chain of
> things. People will ask for everything equivalent to Swing, you will
need
> layout components, ..., etc. It will make everything complicated. In the
> hype of ajax, I think that it's not a good idea to spend a lot of time
to
> develop a server side "Swing". Anyway, I think that Tapestry has a good
> infrastructure, if you really like dynamic components, maybe you can
> create
> a subproject to create a DynamicPage service.
>
> just my two cents.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
