[Jelly] [PROPOSAL] alternate taglib loading mechanism

[John Casey <jd...@commonjava.org>]

Sorry this is a long email, but it might be interesting enough to
read...I dunno...

<speech>

I've just had a minor breakthrough on a xml parsing framework that I'm
completing, and I feel like I owe it to the Jelly folks to share.

I've taken a page or six from both JSP and Jelly taglibs in writing this
xml parser.  It uses a tag-driven approach to register interest in
certain types of nodes, and then register a "callback" class. Also - and
thank you all so much for this - it parses namespace declarations to
dynamically load new taglibs off of the classpath. However, this is
where the epiphany took place.

For months, I've been using an implementation of the Jar specification
service loader (like the one in commons-discovery) to find service
implementations and automagically load the correct one.  For those of
you with quizzical expressions, this amounts to reading a file under
META-INF/services, which is named as the fully-qualified class name for
the service interface, and performing Class.forName() on the first line.

So this brought up a good point in my mind: Jelly has a registered set
of "native" taglibs pre-mapped in a properties file, right?  Anything
else has to be specified as the fully-qualified class name of the tag
library class in order to be used in a script. Why?

Instead, why not create a file under META-INF/parsers called
my-namespace.jtl (jelly-tag-library), and reference it from a script
with jtl:my-namespace (or jelly:my-namespace, if you prefer).  Then,
it's a simple matter of reading the file from the
ClassLoader.getResourceAsStream() input, and parsing it using a dynalib
(like dynatag, thanks again Jelly) to create a "headless" taglib for
jelly?

This technique allows me to embed the tag library definition in my
parser library jars, have a dynamic list of available parsing libraries,
and still refer to each with a terse namespace notation...

Anyway, take or leave it. :)

</speech>

Regards,
John


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Jelly] [PROPOSAL] alternate taglib loading mechanism

["Mark R. Diggory" <md...@latte.harvard.edu>]

<complement>Good Ideas</complement>

I had some thoughts a while back where I wanted to be able to define 
schemas for my taglibraries, to provide some validation features to my 
taglibrary structure for things like tag completion, etc. in XML editors.

If my jelly script could have proper namespaces, I could also provide 
schemas either via the the same jar loading mechanism or via 
schemaLocation attributes... Alternate "Jar URL resolvers" could be 
provided to load the schemas into an xml parser for validation and to 
provide debugging information during the execution of the script.

Eventually someone chimed in that it might be possible to build a schema 
generation tool of some sort that could generate a schema from ones 
taglibrary and tag classes.

This was all around the idea of providing a jelly scripting plugin for 
Eclipse. Unfortunately, a tidal wave of work related projects knocked me 
off this track completely. I would probibly get back into it when I've 
got more time.

-Mark

John Casey wrote:

> Sorry this is a long email, but it might be interesting enough to
> read...I dunno...
> 
> <speech>
> 
> I've just had a minor breakthrough on a xml parsing framework that I'm
> completing, and I feel like I owe it to the Jelly folks to share.
> 
> I've taken a page or six from both JSP and Jelly taglibs in writing this
> xml parser.  It uses a tag-driven approach to register interest in
> certain types of nodes, and then register a "callback" class. Also - and
> thank you all so much for this - it parses namespace declarations to
> dynamically load new taglibs off of the classpath. However, this is
> where the epiphany took place.
> 
> For months, I've been using an implementation of the Jar specification
> service loader (like the one in commons-discovery) to find service
> implementations and automagically load the correct one.  For those of
> you with quizzical expressions, this amounts to reading a file under
> META-INF/services, which is named as the fully-qualified class name for
> the service interface, and performing Class.forName() on the first line.
> 
> So this brought up a good point in my mind: Jelly has a registered set
> of "native" taglibs pre-mapped in a properties file, right?  Anything
> else has to be specified as the fully-qualified class name of the tag
> library class in order to be used in a script. Why?
> 
> Instead, why not create a file under META-INF/parsers called
> my-namespace.jtl (jelly-tag-library), and reference it from a script
> with jtl:my-namespace (or jelly:my-namespace, if you prefer).  Then,
> it's a simple matter of reading the file from the
> ClassLoader.getResourceAsStream() input, and parsing it using a dynalib
> (like dynatag, thanks again Jelly) to create a "headless" taglib for
> jelly?
> 
> This technique allows me to embed the tag library definition in my
> parser library jars, have a dynamic list of available parsing libraries,
> and still refer to each with a terse namespace notation...
> 
> Anyway, take or leave it. :)
> 
> </speech>
> 
> Regards,
> John
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Jelly] [PROPOSAL] alternate taglib loading mechanism

["Mark R. Diggory" <md...@latte.harvard.edu>]

<complement>Good Ideas</complement>

I had some thoughts a while back where I wanted to be able to define 
schemas for my taglibraries, to provide some validation features to my 
taglibrary structure for things like tag completion, etc. in XML editors.

If my jelly script could have proper namespaces, I could also provide 
schemas either via the the same jar loading mechanism or via 
schemaLocation attributes... Alternate "Jar URL resolvers" could be 
provided to load the schemas into an xml parser for validation and to 
provide debugging information during the execution of the script.

Eventually someone chimed in that it might be possible to build a schema 
generation tool of some sort that could generate a schema from ones 
taglibrary and tag classes.

This was all around the idea of providing a jelly scripting plugin for 
Eclipse. Unfortunately, a tidal wave of work related projects knocked me 
off this track completely. I would probibly get back into it when I've 
got more time.

-Mark

John Casey wrote:

> Sorry this is a long email, but it might be interesting enough to
> read...I dunno...
> 
> <speech>
> 
> I've just had a minor breakthrough on a xml parsing framework that I'm
> completing, and I feel like I owe it to the Jelly folks to share.
> 
> I've taken a page or six from both JSP and Jelly taglibs in writing this
> xml parser.  It uses a tag-driven approach to register interest in
> certain types of nodes, and then register a "callback" class. Also - and
> thank you all so much for this - it parses namespace declarations to
> dynamically load new taglibs off of the classpath. However, this is
> where the epiphany took place.
> 
> For months, I've been using an implementation of the Jar specification
> service loader (like the one in commons-discovery) to find service
> implementations and automagically load the correct one.  For those of
> you with quizzical expressions, this amounts to reading a file under
> META-INF/services, which is named as the fully-qualified class name for
> the service interface, and performing Class.forName() on the first line.
> 
> So this brought up a good point in my mind: Jelly has a registered set
> of "native" taglibs pre-mapped in a properties file, right?  Anything
> else has to be specified as the fully-qualified class name of the tag
> library class in order to be used in a script. Why?
> 
> Instead, why not create a file under META-INF/parsers called
> my-namespace.jtl (jelly-tag-library), and reference it from a script
> with jtl:my-namespace (or jelly:my-namespace, if you prefer).  Then,
> it's a simple matter of reading the file from the
> ClassLoader.getResourceAsStream() input, and parsing it using a dynalib
> (like dynatag, thanks again Jelly) to create a "headless" taglib for
> jelly?
> 
> This technique allows me to embed the tag library definition in my
> parser library jars, have a dynamic list of available parsing libraries,
> and still refer to each with a terse namespace notation...
> 
> Anyway, take or leave it. :)
> 
> </speech>
> 
> Regards,
> John
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>