Bump.
Do any devs have an opinion on this? Should I create a jira instead
of asking this on the list?
Here is a quick summary so that no one needs to read through the thread:
1. The ResourceNameIterator encapsulates the
style/variation/localization strategy
2. The ResourceStreamLocator uses it to find html
3. The ComponentStringResourceLocator uses it to find properties
4. The ClassStringResourceLocator delegates to the
ComponentStringResourceLocator to find application properties
This means that all four of the above must be implemented to use a
different strategy. However, if a custom ResourceNameIterator could
be registered in IResourceSettings then 2, 3 & 4 would not have to be
touched.
Do the devs prefer to keep ResourceNameIterator an internal
implementation or expose it on IResourceSettings and simplify the
creation of atypical resource location?
Thank you,
Scott
On Thu, Apr 17, 2008 at 10:36 AM, Scott Swank <[EMAIL PROTECTED]> wrote:
> It seems that the problem is that the ComponentStringResourceLoader
> does not handle the MyApplication.properties (never mind what its
> javadoc says). Instead the ClassStringResourceLoader does. It is
> registered in the Settings constructor.
>
> The ClassSRL ultimately delegates to super
>
> return super.loadStringResource((Class)clazzRef.get(), key, locale, style);
>
> And that means that it calls back up to ComponentStringResourceLoader.
> So I have copied the code (!!!) from ClassSRL into "VcomClassSRL
> extends VcomComponentSRL" and registered VcomClassSRL with my
> application. Now the app.properties are found. Excellent.
>
> This means that I had to write my own:
>
> VcomResourceStreamLoader
> VcomComponentStringResourceLoader
> VcomClassStringResourceLoader
>
> This is a decent step backward from the centralized strategy in Wicket
> 1.2. All of the above could have been eliminated if I could have
> registered my:
>
> VcomResourceNameIterator
>
> With my application. Then the ResourceStreamLoader would have used
> it, the ComponentSRLwould have used it, and the ClassSRL would have
> delegated back to the ComponentSRL.
>
> I don't know whether the Wicket devs want to expose the
> ResourceNameIterator and add it to Settings, but since that is
> currently where the resource location strategy is centralized I would
> prefer that it be exposed.
>
> What do the devs think?
>
> Thank you,
> Scott
>
>
>
> On Wed, Apr 16, 2008 at 10:37 PM, Nino Saturnino Martinez Vazquez Wael
>
>
> <[EMAIL PROTECTED]> wrote:
> > No problem, thank me after the issue are solved:) But you would send the
> > thing to me? I haven't received anything yet FYI...
> >
> >
> >
> > Scott Swank wrote:
> >
> > > Thank you Nino. I'll send the quickstart directly to you since the
> > > list doesn't allow attachments. I'm extracting everything from our
> > > sandbox app that you're not interested in. I do have the behavior
> > > reproduced there.
> > >
> > > - Scott
> > >
> > > On Wed, Apr 16, 2008 at 1:02 PM, Nino Saturnino Martinez Vazquez Wael
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > > Hi Scott
> > > >
> > > > Could you provide a quickstart? I have some time tomorrow...
> > > >
> > > > Scott Swank wrote:
> > > >
> > > >
> > > >
> > > > >
> > > > > I have subclassed ComponentStringResourceLoader so that I can drive
> it
> > > > > from a custom ResourceNameIterator (in particular to look in the
> right
> > > > > directories). In particular, I just overrode
> > > > >
> > > > > public String loadStringResource(Class clazz, final String key,
> > > > > final Locale locale, final String style)
> > > > >
> > > > > and only changed the line
> > > > >
> > > > > ResourceNameIterator iter = new ResourceNameIterator(path, style,
> > > > > locale, "properties,xml");
> > > > >
> > > > > to use our iterator. Now it cannot find myApplication.properties and
> > > > > I am at a bit of a loss as how this class ever got to
> > > > > myApplication.properties. When it is constructing its list of
> > > > > components it clearly stops at the Page and I don't see how it would
> > > > > ever get to the Application.
> > > > >
> > > > > private List getComponentStack(final Component component)
> > > > > {
> > > > > // Build the search stack
> > > > > final List searchStack = new ArrayList();
> > > > > searchStack.add(component.getClass());
> > > > >
> > > > > if (!(component instanceof Page))
> > > > > {
> > > > > // Add all the component on the way to the Page
> > > > > MarkupContainer container =
> > component.getParent();
> > > > > while (container != null)
> > > > > {
> > > > > searchStack.add(container.getClass());
> > > > > if (container instanceof Page)
> > > > > {
> > > > > break;
> > > > > }
> > > > >
> > > > > container = container.getParent();
> > > > > }
> > > > > }
> > > > > return searchStack;
> > > > > }
> > > > >
> > > > > What am I missing?
> > > > >
> > > > > Thank you,
> > > > > Scott
> > > > >
> > > > > On Tue, Apr 15, 2008 at 12:30 PM, Scott Swank <[EMAIL PROTECTED]>
> > > > >
> > > > >
> > > > wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > > > Previously we retrieved the CompoundResourceStreamLocator and added
> > > > > > our ResourceStreamLocator to it. In 1.2 did this take care of
> > > > > > StringResourceLoader too?
> > > > > >
> > > > > > WebApplicationPath resourceFinder = (WebApplicationPath)
> > > > > > getResourceSettings().getResourceFinder();
> > > > > > resourceFinder.add(Env.getInstance().getAthenaDocRoot());
> > > > > >
> > > > > > CompoundResourceStreamLocator locator =
> > > > > > (CompoundResourceStreamLocator)
> > > > > > getResourceSettings().getResourceStreamLocator();
> > > > > > locator.add(0, new WebPageResourceStreamLocator(resourceFinder));
> > > > > >
> > > > > > Thank you,
> > > > > > Scott
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 10:55 AM, Scott Swank
> > <[EMAIL PROTECTED]>
> > > > > >
> > > > > >
> > > > >
> > > > wrote:
> > > >
> > > >
> > > > >
> > > > > > > We are finally upgrading to Wicket 1.3 (in particular to 1.3.3
> > from
> > > > > > > 1.2.6) and our StringResourceModels can no longer find their
> > > > > >
> > > > > >
> > > > >
> > > > property
> > > >
> > > >
> > > > >
> > > > > > > files, which leaves our web pages containing the following:
> > > > > > >
> > > > > > > [Warning: String resource for 'tickets' not found]
> > > > > > >
> > > > > > > Our application init method contains:
> > > > > > >
> > > > > > > IResourceFinder finder =
> > > > > >
> > > > > >
> > > > >
> > > > getResourceSettings().getResourceFinder();
> > > >
> > > >
> > > > >
> > > > > > > IResourceStreamLocator streamLocator = new
> > > > > > > WebPageResourceStreamLocator(finder);
> > > > > > >
> getResourceSettings().setResourceStreamLocator(streamLocator);
> > > > > > >
> > > > > > > and in our ResourceStreamLocator I added the following with a
> > break
> > > > > > > point on the System.out line:
> > > > > > >
> > > > > > > public IResourceStream locate(final Class clazz, String path,
> > > > > >
> > > > > >
> > > > >
> > > > final
> > > >
> > > >
> > > > >
> > > > > > > String variationAndStyle, final Locale locale, String
> extension)
> > > > > > > {
> > > > > > > if (!"html".equals(extension) && !path.endsWith(".js") &&
> > > > > > > !path.endsWith(".css"))
> > > > > > > {
> > > > > > > System.out.println("break");
> > > > > > > }
> > > > > > > ...
> > > > > > >
> > > > > > > I never see the locate() method called in an attempt to find
> the
> > > > > > > properties. Where should I be looking?
> > > > > > >
> > > > > > > Thank you,
> > > > > > > Scott
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > --
> > > > -Wicket for love
> > > >
> > > > Nino Martinez Wael
> > > > Java Specialist @ Jayway DK
> > > > http://www.jayway.dk
> > > > +45 2936 7684
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> > >
> > >
> >
> > --
> > -Wicket for love
> >
> > Nino Martinez Wael
> > Java Specialist @ Jayway DK
> > http://www.jayway.dk
> > +45 2936 7684
> >
> >
> > ---------------------------------------------------------------------
> > 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]
