Re: [xmlc] DocumentLoaderImpl Cache Keys

I think I understand what you're saying, but here's
the catch, I don't even want to run the interface
generation on my alternate html files.  Let me explain
a little better how my project is laid out...

I've got an e-commerce webapp that I want to host
multiple sites with.  So what I've done is this:

1) create a standard product page template,
/projects/webapp/root/product.html.
2) generate xmlc interfaces, etc. 
com.webapp.xmlc.productHTML
3) write my server-side code to put data into a
productHTML page.
4) run my webapp with a config file that sets up two
page roots, "/projects/site1/root/" and
"/projects/webapp/root/"

Now, whenever an HTML designer for Site1 doesn't like
the default layout of the product page from
/projects/webapp/root/product.html, he can create a
/projects/site1/root/product.html and, BAM!, the
application automatically (after a restart to clear
the cache) uses his file instead of the default one.

Notice that no XMLC generation had to happen for this
to work.  It simply uses the fall-through magic
already built into the "multiple page roots" feature
of XMLC's DocumentLoaderImpl.

And there are lots of sites!  I'd rather not have to
create a build target for each site in my ant script
if I don't have to.  Plus, my set-up allows for the
HTML designers for my various sites to be in other
departments or even external client companies, and, as
long as they don't break the id attributes in the
document, they have complete control over the layout
without every speaking to a developer or running a
build script.  I hope that you can see the value in
the structure that I've built and understand my
aversion to generating interfaces when it can be
avoided.

The caching change I suggested would allow me to
provide this additional "per-product html page"
feature while preserving the elegance of my set-up.

Simply put, I want to load multiple HTML files into my
HTMLImpl at runtime.  This looks very easily possible.
 Perhaps a more elegant solution should be attempted
and this "runtime document switching" be billed as a
new feature?

Erik

--- Jacob Kjome <hoju@xxxxxxxx> wrote:

> 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
> 
=== message truncated ===> 
> --
> 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
> 



 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121


--
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