On Jan 27, 2006, at 11:11 AM, [EMAIL PROTECTED] wrote:
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.
You shouldn't be doing your layout on a page by page basis anyway,
you should be using some kind of Border component (as described in
Tapestry in Action). Components can have localized templates too, so
changing the layout of a page on a per locale basis is as simple as
writing a new Border component template. Between that and using
message catalogs instead of raw text in pages/components you can have
totally different layouts without needing to modify the pages at all.
I think the real problem with Tapestry is that it has a fairly steep
learning curve. But once you know it you can create very highly
dynamic pages without needing to mess around with instantiating
components in Java. So the question is, how to make the learning
curve less steep. Given what I've seen with using Tapestry 4 so far,
I'm pretty convinced Howard understands the learning curve issue and
is making definite progress.
The one thing I would like to see addressed, as others have
mentioned, is the whole problem with getting access to what's
rendered inside a For component. But that's not something I've
needed to deal with very often, so I'm not going to lose sleep over it.
--Chris
"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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
