Re: [xmlc] DocumentLoaderImpl Cache Keys

What, no interest, or have you just not had a chance to 
respond?  Your use-case is compelling and I encourage you to provide 
a patch to enable the capability.

Jake

At 11:32 PM 1/16/2007, you wrote:
>
>You had me at "BAM!" :-)
>
>Tell you what.  Grab the latest XMLC source, implement your strategy
>in whatever way you see fit, test it in your setup to make sure it
>works, and provide a patch (unified diff) for review.  A small sample
>app describing and showing the new functionality in action would be a
>nice touch (as well as increase the chances of your changes being
>committed, since it will make it easier for me to verify that it
>works).  If the changes are reasonable and don't cause harm to
>existing functionality, I will commit them.  DocumentLoaderImpl is
>identical between the 2.2.xx branch and the HEAD (2.3 development),
>so if that's the only file that is touched, then a single patch will
>be all that is required to get this into both the 2.2.xx and 2.3 releases.
>
>Oh, and please create a new feature request on the Forge site [1] for
>this.  Post all attachments there.  I suggest wrapping the
>attachments in a zip file.  Let me know when things are ready for review.
>
>
>Jake
>
>[1] http://forge.objectweb.org/projects/xmlc/
>
>At 05:47 AM 1/16/2007, you wrote:
> >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
>
>
>
>
>--
>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



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