You sometimes do have to change layout on a page by page layout when
you do i18n stuff, especially if some of the languages you're translating
into are significantly more verbose than English (<cough> german <cough>).
So a nice little set of widgets that do, say:
Label1 text1
Label2 text2
Might not fit if the german translation of label is
InevitableReallyLongGermanAlliterativeLabel text1
FiendishlyShortForGerman test2
If you're using pretty much *any* fixed size elements on your page,
you're gonna have to tweak the sizing for most foreign languages. If you've
managed to survive with only proportionate sizing e.g. "width="30%" then
you're all right, but the moment you do width="120px" you've bought yourself
problems in the localization field.
--- Pat
> -----Original Message-----
> From: Chris Conrad [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 27, 2006 6:05 PM
> To: Tapestry users
> Subject: Re: tapestry not really component based?
>
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
