Re: [xmlc] DocumentLoaderImpl Cache Keys

Quoting Erik Rasmussen <i_am_erik@xxxxxxxxx>:

> Jake,
>
> I meant "interface", since that's what I'm passing it,
> but you're right.  By the time it gets down to that
> method, it's already guessed the Impl class of the
> interface and is using that.
>
> Here's the use case:  I've got a product.html that
> displays one product on my site.  It takes an "id"
> parameter that the server uses to look up the
> product's info from the database and populate the html
> file via XMLC setText() methods.  Almost all the
> products should be displayed with the same layout,
> that of product.html.  But I have a handful of
> products that need a completely unique layout special
> to that product.  So what I want to do is have it,
> when you request /product.html?id=123, it should try
> to find a product-123.html file to use.

If you know that you need to load up product123.html, then why not load up
Product123HTMLImpl.class, which wraps said HTML file?  This would require no
changes to XMLC and allow you to accomplish what you desire, as far as I can
tell.

Define a markup file that contains the Id's that define the common interface,
such as "commonProductInterface.html".  The code generation for this markup can
be simply an interface instead of Impl or both.  The easiest way to do this
would be to compile this once and use it as a library for your main markup
classes.  Now in your options.xmlc, add the following line...

-implements com.mypackage.xmlc.CommonProductInterfaceHTML

If only a few markup files are to implement the ProductHTML interface, then you
can leave your options.xmlc file with only the common stuff and create specific
XMLC files for each markup file with the "-implements" option such as...

product.html    --> product.xmlc
product123.html --> product123.xmlc
product500.html --> product500.xmlc

This way, you can compile your other markup files such as invoice.html, which
may not implement the CommonProductInterfaceHTML interface, in the same XMLC
compile run, with the same options.xmlc, without failing because it is
erroneously designated to implement an interface that it clearly shouldn't be
implementing.

Alternatively, you can split up your markup, options.xmlc, and use separate XMLC
compile runs based on which sets of markup implement which interface.

Of course you can always use dynamic loading, but then you lose the setTextXXX()
and getElementXXX() methods.  It would, however, solve your caching problem.  As
long as the markup file is named differently, it will be cached separately.


Jake

>  If it can't
> find one, it should fall back to the default
> product.html.  If it finds the specific one, I want it
> read into a productHTMLImpl class to be populated
> using the productHTML interface.
>
> If I could just get more control over the caching
> mechanism, I could accomplish this without having to
> code any new interfaces or change my xmlc interface
> generation in my ant script at all.
>

Seems to me that changing configuration, such as in the XMLC metadata file(s) or
the Ant script, to implement supported behavior is more desirable than forcing
changes to XMLC to allow for custom extension to implement non-standard
behavior , which can already be achieved in a standard way.  No?

> I already have it properly selecting product-123.html
> when the parameter is there, but then that DOM object
> gets cached and used for all other product.html
> requests.
>

Your initial approach loading a different markup file based on a request
parameter and business logic is fine.  However, I suspect that the approach
you've chosen to lobby for, while creative, is based on a lack of knowledge of
the existence of the approaches I explained above.

Please try out one or more of the approaches I described above.  If none of them
 meet your needs, we can discuss a more comprehensive solution to the problem,
such as pluggable caching strategy or generated classes that wrap more than one
markup file.  I'd like to avoid one-off hacks to meet a specific need while
neglecting other possible needs.

> Does that make any more sense?  Thanks for the quick
> response.
>

It's pretty much what I was thinking, but thanks for clarifying.

Jake

> Erik
>
>
> --- Jacob Kjome <hoju@xxxxxxxx> wrote:
>
> > At 06:56 AM 1/12/2007, you wrote:
> >  >Here's my problem...  I want to switch which html
> > file is used for a
> >  >given generated interface X based on some request
> > values.
> >  >
> >
> > Interface or Class?  I suspect you are talking about
> > Class, not
> > Interface.  Read on...
> >
> >  >I've gotten this ALMOST working by extending
> > StandardDocumentLoader
> >  >and overriding  getSourceFileName(Class).  The
> > problem is that this
> >  >value is then cached in the DocumentLoaderImpl
> > superclass.  Then, when
> >  >I make another request that should use a different
> > html file for
> >  >interface X, it uses the first html file that it
> > already has cached.
> >  >
> >
> > This is why I suspect you are talking about Class,
> > not
> > Interface.  getSourceFileName() calls
> > getClassConstant() to obtain
> > the source file associated with the Class, not
> > Interface.  For
> > instance, the following might be in your generated
> > XMLC Class...
> >
> > public static final String XMLC_SOURCE_FILE =
> > "xmlc/demo/Welcome.html"
> >
> > You may have multiple classes, with different source
> > files, all
> > implementing the same interface.  If the document
> > loader sees a new
> > class it hasn't seen before, it will be loaded and
> > cached separately
> > from any other class, even if both classes implement
> > the same interface.
> >
> > Does this not work for you?   Maybe if you explain
> > your use-case a
> > little more, it will make more sense to me.   I'm
> > open to changes,
> > but I'm not sure I see the necessity of them at this
> > point,
> > especially when there are other ways to do it.
> >
> >
> > Jake
> >
>
>
>
>
____________________________________________________________________________________
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html
>
>





--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws