> I don't find it very practical to have switch statements for EVERY link,
> such as:
Continuing this discussion, if I may...
I'm experimenting a little more with making things a little nicer for
developing i18n apps. I noticed another problem.
For a particular page, I have a link that should be rendered in one
language, but not in others. I am using the "out-of-the-box" approach to
l10n by using Page.html and Page_xx.html.
If I switch between locales, since the link appears in one page and not
in the other, but the component structure is built only once on
instantiation of the page class. then this will cause an error.
The only way I see to get around the error is to add an invisible link
to the page with the sole purpose of shutting up complaints from the
framework.
Are things supposed to be this way, or am I doing something wrong?
If things are supposed to be this way, I'm not sure that this is the
ideal solution.
So, I see one of:
- links should not be componentized
- there needs to be special treatment for links
(risks making the codebase "ugly", but helps
with useability, SOC)
- there could be some kind of i18n layer. Really,
these problems only occur when trying to i18nize
an app
The rationale for the above is that for "regular" components, these
SHOULD be taken care of by programmers, or at the very least should
require more communication between programmers and authors. Links,
however, are a little more gray. An HTML author should be able to add
links (more than one, perhaps one in one language and not in another)
with more freedom without worrying about breaking the system.
Thoughts?
Cheers,
Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
