incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dirk Frederickx" <dirk.frederi...@gmail.com>
Subject Re: Javascript additions
Date Sun, 06 Apr 2008 19:40:53 GMT
Some more thoughts , to reduce the javascripts and client DOM-parsing
overhead ....


JSPWiki is already equipped with some nice plugin concepts.   We could
extend the jspwiki_module.xml with something like this:

   <javascript name="jspwiki_extra.js">
      <author>Janne Jalkanen</author>
      <minVersion>2.7</minVersion>
      <cssclass>collapsible</cssclass>  ??or even an xpath expression??
      <cssclass>category</cssclass>
      <cssclass>prettify</cssclass>
      ....
   </javascript>

The jspwiki engine would then parse (the DOM tree of) a page.

If it contains elements with class="collapsbile" or class="category",
the related javascript file would be included in the page header.

This can be done via

   TemplateManager.addResourceRequest( context, "script",  "... path
to jspwiki_extra.js" );


= = = =

In the commonheader.jsp, there is already the line ::

<wiki:IncludeResources type="script"/>

which then would render

<script type="text/javascript" src="..path to jspwiki_extra.js"></script>




I assume the above would be usable as well for external javascript
contributions ?




dirk


On Sun, Apr 6, 2008 at 12:33 AM, Janne Jalkanen
<Janne.Jalkanen@ecyrd.com> wrote:
>
> > At the server, the DOM tree could be pre-processed to check which
> > %%styles are used.
> > The js could be split in several pieces which, depending on the needed
> > styles, would be loaded to the client.
> >
>
>  Yes, we have the mechanism for this already with the Resource Requests.
>
>
>
> > In some cases it would be feasible to move the preparation block to
> > the server. Eg. edit-section links could be added  by the server iso
> > the client, DOM manipulation to convert an unordered list into a
> > collapsible list could be done in the server, etc.
> >
>
>  Yupyup, exactly this kind of stuff I was talking about.  The edit-section
> links would be trivial to hide in CSS, if the template for some reason
> didn't want to use them.
>
>
>
> > I don't think Stripes will change that picture.  It'll sure make
> > template writing less complex, but will still need client side
> > javascript to achieve certain functionalities. And require us to find
> > a good balance between server/client side.
> >
>
>  What Stripes is good for is that it will help us to make this functionality
> more modular - easier to encapsulate the server-side and the client-side
> things.  At the moment, things are pretty monolithic (though they are nicely
> separated inside these monolithic files).
>
>  /Janne
>

Mime
View raw message