PluginManager, PluginContent, and XPath

'lo;

May I suggest the following kind of change to our
PluginManager?
Instead of
                 PluginContent result = new PluginContent(
plugin,  
arglist );
                 return result;

I'd wrap the Content (XPath text()) object into a
resolvable Element:

                 Element result = new Element 
( WIKIPLUGIN_ELEMENT_NAME );
                 result.addContent( new PluginContent(
plugin,  
arglist ) );
                 return result;

This lets us use XPath to easily locate the plugins at any
point  
prior to rendering:

                 String query = "//" +
WIKIPLUGIN_ELEMENT_NAME + "/ 
text()";
                 XPath xp = XPath.newInstance( query );
                 List<PluginContent> plugs =
xp.selectNodes(...);

I'm not sure if this is immediately useful in stock
JSPWiki, but I  
can imagine there will be others who'd like to get hold of
a page's  
plugins before rendering, and this certainly helps.

Comments? Current functionality isn't affected, but an
extra object  
is created per plugin; what's the impact on page caching
and memory?

//ebu
_______________________________________________
Jspwiki-users mailing list
Jspwiki-usersecyrd.com
http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users

Erik,

In theory, that sounds like a nice capability.  In practice,
however, 
(as you suggest) it's not clear how/why you would use it. 
Could you 
give an example or two of why one would want to access the
plugin prior 
to it being executed?

Regards,

Terry


Erik Bunn wrote:
>
> 'lo;
>
> May I suggest the following kind of change to our
PluginManager?
> Instead of
>                 PluginContent result = new
PluginContent( plugin, 
> arglist );
>                 return result;
>
> I'd wrap the Content (XPath text()) object into a
resolvable Element:
>
>                 Element result = new Element(
WIKIPLUGIN_ELEMENT_NAME );
>                 result.addContent( new PluginContent(
plugin, arglist 
> ) );
>                 return result;
>
> This lets us use XPath to easily locate the plugins at
any point prior 
> to rendering:
>
>                 String query = "//" +
WIKIPLUGIN_ELEMENT_NAME + 
> "/text()";
>                 XPath xp = XPath.newInstance( query );
>                 List<PluginContent> plugs =
xp.selectNodes(...);
>
> I'm not sure if this is immediately useful in stock
JSPWiki, but I can 
> imagine there will be others who'd like to get hold of
a page's 
> plugins before rendering, and this certainly helps.
>
> Comments? Current functionality isn't affected, but an
extra object is 
> created per plugin; what's the impact on page caching
and memory?
>
> //ebu
> _______________________________________________
> Jspwiki-users mailing list
> Jspwiki-usersecyrd.com
> http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
>
_______________________________________________
Jspwiki-users mailing list
Jspwiki-usersecyrd.com
http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users

On Jul 14, 2006, at 15:18 , Terry Steichen wrote:

> Erik,
>
> In theory, that sounds like a nice capability.  In
practice,  
> however, (as you suggest) it's not clear how/why you
would use it.   
> Could you give an example or two of why one would want
to access  
> the plugin prior to it being executed?

Actually, it's a question of executing a plugin before it
is rendered.

My concrete example:
Imagine a wikipage with, say, 100 plugins, most of which
actually  
access external systems in the background. The bottleneck
may be tcp  
connections, or the processing capacity of the server farm
serving  
certain types of requests, or it may be that some sort of
operation  
just plain takes time, no matter how many multiprocessor
number  
crunchers we have in the back.

At the moment, when a user arrives to a page, each plugin is
hit in  
sequence, and the rendering processor sits there until the
plugin is  
done.
What I'm testing right now is a parallelizing plugin
executor that  
starts the plugin work before the XHTMLRenderer's outputter
starts.  
It will still block, waiting for input, but upcoming plugins
are  
already executing, and the total execution time will be
smaller.

The Element wrapping is a minor change that would be nice to
have in  
just one place. Other changes involve modularizing the
WikiRenderer  
and (maybe) PluginManager. These don't change JSPWiki
functionality,   
but allow you to provide alternatives geared for a kind
parallelization.

This is of absolutely no use to your single uniprocessor
service, but  
WikiFarms might benefit a lot.

(Now, before you ask, I'm not sure a wikipage with 100+
plugins is  
good organization of data, but this is what our users are
ending up  
with. I'm also running a battle on that front.;)

//ebu
_______________________________________________
Jspwiki-users mailing list
Jspwiki-usersecyrd.com
http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users