You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Janne Jalkanen <Ja...@ecyrd.com> on 2008/04/05 18:19:19 UTC
Javascript additions
Folks,
I'm getting a bit worried about all the Javascript we have in the
current template. First of all, it's quite a lot of stuff to send
around (several tens of kilobytes, even when compressed); and second,
it's taking quite a lot of processing time, as the DOM tree gets
walked quite often. It is for example choking my phone browser
pretty thoroughly, and also taking quite a lot of memory.
Also, it relies quite a lot on the default template and default
editor, which might make it a bit complicated for people to add the
additional stuff to other templates or editors.
So, the question is: what kind of functionality we should and could
move to the back-end? I'm thinking of common tasks, some processing
of the DOM tree (which could take advantage of the DOM tree caching
that we have), and in general things that have been found to be good
and should be shared across all templates and editors.
Also, the advantage would be that if it were done in Java in the back-
end, it would make it easier for people to contribute to. I'll have
to confess that a lot of the JS stuff is going above my head, so I
can't really contribute - I fear that I break something. The fact
that we don't have an unit test suite for the JS worries me, too.
Any suggestions? Dirk, you know the stuff better than anyone else.
Do you have any suggestions on the stuff that we should start working
on transferring?
/Janne
Re: Javascript additions
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> The best approach here would be to build a dedicated template fit for
> mobile devices.
Not necessarily. The 2.4 template works very nicely on my mobile
phone as well.
/Janne
Re: Javascript additions
Posted by Dirk Frederickx <di...@gmail.com>.
Janne,
The best approach here would be to build a dedicated template fit for
mobile devices.
The iPHONE gui style can be a good inspiration.
On a mobile device, with limited screen space, only the main page
content should be shown, with a few hyperlinks or buttons linking to
favorites, breadcrumbs, search page, attachment list, etc. Also info
pages, upload pages, login, etc. would look different.
On a desktop, on the otherhand, you want this info to be available in one shot.
I've been doing some experiments with the iUI from Joe Hewitt
(p://code.google.com/p/iui/)
This would make a good basis for the wiki mobile template.
dirk
On Sun, Apr 6, 2008 at 12:26 AM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>
> > Allthough Janne is complaining about performance, my experience so far
> > is that the DOM preparation is pretty fast. JS is mostly cached,
> > execution 'on-page-load' (even on IE) is also fast.
> >
>
> Be aware that I work for Nokia, so I'm trying this stuff out on phone
> browsers (which in general have processors in the hundreds of MHz, typically
> ten times less than most desktop browsers; and a few tens of megs of memory
> as opposed to hundreds of megs). The 2.6 template BTW has some rather
> interesting rendering bugs - all content is squashed to about ten pixels
> wide on the S60 3.0 browser.
>
> Over the next few years, it is estimated that there will be a billion
> people joining the internet, for whom the cell phone browser is the first
> and only browser they have ever used.
>
> It might be nice to ensure that JSPWiki is a viable choice to those people
> as well. I would consider mobile support as an important part of the future
> - and considering that the US seems to be slowly waking up to the usefulness
> of mobile browsing with the iPhone, I would guess that quite a few services
> will be tackling mobility soon.
>
> /Janne
>
Re: Javascript additions
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Allthough Janne is complaining about performance, my experience so far
> is that the DOM preparation is pretty fast. JS is mostly cached,
> execution 'on-page-load' (even on IE) is also fast.
Be aware that I work for Nokia, so I'm trying this stuff out on phone
browsers (which in general have processors in the hundreds of MHz,
typically ten times less than most desktop browsers; and a few tens
of megs of memory as opposed to hundreds of megs). The 2.6 template
BTW has some rather interesting rendering bugs - all content is
squashed to about ten pixels wide on the S60 3.0 browser.
Over the next few years, it is estimated that there will be a billion
people joining the internet, for whom the cell phone browser is the
first and only browser they have ever used.
It might be nice to ensure that JSPWiki is a viable choice to those
people as well. I would consider mobile support as an important part
of the future - and considering that the US seems to be slowly waking
up to the usefulness of mobile browsing with the iPhone, I would
guess that quite a few services will be tackling mobility soon.
/Janne
Re: Javascript additions
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> JSPWiki is already equipped with some nice plugin concepts. We could
> extend the jspwiki_module.xml with something like this:
Mmm... perhaps. Actually, I would like to get rid of
jspwiki_module.xml and move to Annotations, now that those
are possible.
But the idea sounds useful.
> I assume the above would be usable as well for external javascript
> contributions ?
Yup. Would make a nice way to allow "Javascript plugins" - and in
fact, enable most of our functionality as JS plugins as well.
/Janne
Re: Javascript additions
Posted by Dirk Frederickx <di...@gmail.com>.
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
<Ja...@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
>
Re: Javascript additions
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> 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
Re: Javascript additions
Posted by Dirk Frederickx <di...@gmail.com>.
About reducing size of js: (apart from compression)
Approx. 1/3 of the JS is related to 'dynamic styles' which may or may
not be applicable to certain pages.
Certain styles are less essential to the basic wiki functionality. (we
may even consider to remove them from the core jspwiki package)
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.
This could be done in a pluggable way
* jspwiki-common.js is always loaded
* jspwiki-extras.js is only loaded in case some %%styles are present
This would also allow for other users to contribute js-plugins.
- - - -
About moving more stuff to the server:
The current jspwiki-common.js is build up in a modular way. These js
modules all follow a similar pattern.
Most of them have some 'on-page-load' functionality which performs
some preparation work such as dom manipulation, registering
event-handlers. The remaining part contains event handlers, ajax
routines, visual effects, which can only be executed in a browser on
the client.
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.
The main driver for this is performance.
Allthough Janne is complaining about performance, my experience so far
is that the DOM preparation is pretty fast. JS is mostly cached,
execution 'on-page-load' (even on IE) is also fast.
==> can we have some feedback on this from other people on this
mailing-list ...?
For some cases (such as mobile devices), I think we should consider to
make a dedicate template. Such simplified template would not contain
advanced effects , ajax autocompletion searches, attachment viewers,
left-menu's, tabs, breadcrumbs, etc... and better fit to the
limitation of screen size, and mouse/keyboard/touch-screen input.
Eventually, the standard jspwiki package would have 2
default-templates : (i) feature rich, targetting desktops with A-grade
browsers, and (ii) a simplified template targetting mobile-devices,
iphone, devices on slow networks.
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.
dirk
On Sat, Apr 5, 2008 at 9:10 PM, Janne Jalkanen <Ja...@ecyrd.com> wrote:
>
> I guess the question is if there are any refactorings that we could do now?
> Something that will end up in ActionBeans in 3.0?
>
> /Janne
>
>
>
> On 5 Apr 2008, at 20:53, Andrew Jaquith wrote:
>
> > This is a key reason I want to start using Stripes... Will force some
> refactoring...
> >
> > On Apr 5, 2008, at 9:19, Janne Jalkanen <Ja...@ecyrd.com> wrote:
> >
> >
> > > Folks,
> > >
> > > I'm getting a bit worried about all the Javascript we have in the
> current template. First of all, it's quite a lot of stuff to send around
> (several tens of kilobytes, even when compressed); and second, it's taking
> quite a lot of processing time, as the DOM tree gets walked quite often. It
> is for example choking my phone browser pretty thoroughly, and also taking
> quite a lot of memory.
> > >
> > > Also, it relies quite a lot on the default template and default editor,
> which might make it a bit complicated for people to add the additional stuff
> to other templates or editors.
> > >
> > > So, the question is: what kind of functionality we should and could move
> to the back-end? I'm thinking of common tasks, some processing of the DOM
> tree (which could take advantage of the DOM tree caching that we have), and
> in general things that have been found to be good and should be shared
> across all templates and editors.
> > >
> > > Also, the advantage would be that if it were done in Java in the
> back-end, it would make it easier for people to contribute to. I'll have to
> confess that a lot of the JS stuff is going above my head, so I can't really
> contribute - I fear that I break something. The fact that we don't have an
> unit test suite for the JS worries me, too.
> > >
> > > Any suggestions? Dirk, you know the stuff better than anyone else. Do
> you have any suggestions on the stuff that we should start working on
> transferring?
> > >
> > > /Janne
> > >
> >
>
>
Re: Javascript additions
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
I guess the question is if there are any refactorings that we could
do now? Something that will end up in ActionBeans in 3.0?
/Janne
On 5 Apr 2008, at 20:53, Andrew Jaquith wrote:
> This is a key reason I want to start using Stripes... Will force
> some refactoring...
>
> On Apr 5, 2008, at 9:19, Janne Jalkanen <Ja...@ecyrd.com>
> wrote:
>
>> Folks,
>>
>> I'm getting a bit worried about all the Javascript we have in the
>> current template. First of all, it's quite a lot of stuff to send
>> around (several tens of kilobytes, even when compressed); and
>> second, it's taking quite a lot of processing time, as the DOM
>> tree gets walked quite often. It is for example choking my phone
>> browser pretty thoroughly, and also taking quite a lot of memory.
>>
>> Also, it relies quite a lot on the default template and default
>> editor, which might make it a bit complicated for people to add
>> the additional stuff to other templates or editors.
>>
>> So, the question is: what kind of functionality we should and
>> could move to the back-end? I'm thinking of common tasks, some
>> processing of the DOM tree (which could take advantage of the DOM
>> tree caching that we have), and in general things that have been
>> found to be good and should be shared across all templates and
>> editors.
>>
>> Also, the advantage would be that if it were done in Java in the
>> back-end, it would make it easier for people to contribute to.
>> I'll have to confess that a lot of the JS stuff is going above my
>> head, so I can't really contribute - I fear that I break
>> something. The fact that we don't have an unit test suite for the
>> JS worries me, too.
>>
>> Any suggestions? Dirk, you know the stuff better than anyone
>> else. Do you have any suggestions on the stuff that we should
>> start working on transferring?
>>
>> /Janne
Re: Javascript additions
Posted by Andrew Jaquith <an...@mac.com>.
This is a key reason I want to start using Stripes... Will force some
refactoring...
On Apr 5, 2008, at 9:19, Janne Jalkanen <Ja...@ecyrd.com>
wrote:
> Folks,
>
> I'm getting a bit worried about all the Javascript we have in the
> current template. First of all, it's quite a lot of stuff to send
> around (several tens of kilobytes, even when compressed); and
> second, it's taking quite a lot of processing time, as the DOM tree
> gets walked quite often. It is for example choking my phone browser
> pretty thoroughly, and also taking quite a lot of memory.
>
> Also, it relies quite a lot on the default template and default
> editor, which might make it a bit complicated for people to add the
> additional stuff to other templates or editors.
>
> So, the question is: what kind of functionality we should and could
> move to the back-end? I'm thinking of common tasks, some processing
> of the DOM tree (which could take advantage of the DOM tree caching
> that we have), and in general things that have been found to be good
> and should be shared across all templates and editors.
>
> Also, the advantage would be that if it were done in Java in the
> back-end, it would make it easier for people to contribute to. I'll
> have to confess that a lot of the JS stuff is going above my head,
> so I can't really contribute - I fear that I break something. The
> fact that we don't have an unit test suite for the JS worries me, too.
>
> Any suggestions? Dirk, you know the stuff better than anyone else.
> Do you have any suggestions on the stuff that we should start
> working on transferring?
>
> /Janne