What comes into my mind. MarkupResourceStream keeps a copy of
containerInfo. May be that requires less changes to your code. Though
I still think that using the StreamLocator is the much cleaner
approach.
Juergen
On 1/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> 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()
>
> > 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.
>
> 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=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
