Juergen Donnerstag wrote:
On 1/19/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Can't say I like the first approach much. When I was implementing the
localization before, that was the first thing i tried. Didn't like it
then, but maybe things have changed.
Still, it won't be possible for me to use Localizer, right? I'll have to
load the properties files myself.
why not? Application.get().getResourceSettings().getLocalizer()
Sure I can. I just didn't realized, that I can pass search stack to
getString. I thought that I need component instance to call getString,
which is not true.
Having provided Container in MarkupStreamFactory would really be
helpful, but it seems that my usecase is not very common.
I don't think many people have the requirement to load the markup from
other source than files (I regard transforming a file in that sense as
none-std as well), but I think the resource stream solution is realy
much clearer and better (than replacing MarkupParser and
XmlPullParser). It should be completely none-intrusive to wicket.
Okay, it seems I'll go this way. Btw, what do you thing would be the
best way of determining stream encoding? (since it stream, not reader).
Should I parse the begining looking for <?xml and if nothing like that
is found use the default markup parser encoding? Is that what markup
parser does?
-Matej
Juergen
I guess I'll try with MarkupResourceStream.
-Matej
Juergen Donnerstag wrote:
Just thinking out loud. Not sure it realy works. Like you would create
your own IResourceStream to read markup from say a database instead of
file, it is possible to create a resource stream which first calls the
default file resource stream and than applies the transformation and
that in turn is forwarded to the parsers. Because a resource stream
knows the filename it should be possible to find the properties file
as well. Register your resouce finder with the
DefaultResourceStreamLocator and you are done.
Reason why we removed Container: Each component has a ref to its
parent and that has a ref to its parent etc. Essentially you have the
whole component tree associated with it which could quite some memory.
And because markup is read in a separate thread (at least in
development mode) we implicitly consumed large chunks of memory. We
are now using ContainerInfo to keep just the information needed.
Though we could add it to MarkupParserFactory, IMO it is cleaner to
use the resoource approach mentioned above. In case you have any
difficulties implementing it, please let me know.
Juergen
Juergen
On 1/19/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Hi,
in 1.1, I had my own markup parser and XMLPullParser, that basically
replaced all ${key} strings in Markup with the values from associated
properties files.
This no longer works for 1.2, because
MarkupParserFactory.newMarkupParser does not provide the
MarkupContainer, for which the markup is parsed. So I can't replace the
${key} strings in markup, because I don't know to which component the
markup belongs.
I know there is a <wicket:message key="..."></wicket-message> solution,
but it has two drawbacks for me. It's really verbose and it can't be
used in tag attributes (e.g. <button value="${buttonCaption}"/>)
Any ideas?
-Matej
-------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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=k&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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=k&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
