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 jollies (was: weird access rights issue)
Date Wed, 20 Aug 2008 10:44:02 GMT
Hi Terry,

Maybe JS is esoteric for many of the jspwiki folks ...  as the core of
jspwiki is around java.  But by incorporating the brushed-template as
default, we of-course also added some extra js weight to jspwiki.
Alternatively jspwiki could choose to go java all the way and eg go
for GWT kind of technology.  Personally I think JS is pretty
accessible (and readable) and shoudl not cause to much of a burden to
java-developers ---- but of course who am I to say so :-)


v2.7.x is still in alpha, and we are ironing out the last bugs.
Section Editing was added, and still caused issues wrt to adding
comments.  And sometimes bugs only come to the surface in strange
ways.


The approach I try to take wrt to JS is the following:


1) JSPWiki should be able to run without JS active; you'll only miss
some ''not-essential'' functionality, such as presentational
enhancements, table sorting, etc.
Browser specific stuff runs on the client.  All gui stuff relies on
html and css to a maximum extend.

2) The JS is *supposed* to be written in a modular way so it should be
rather straighforward to selectively remove the parts of the js which
you think you don't need or are bothering you.
This requires of course JS-know-how. And some knowledge how the
jspwiki JS is hooked into JSPWiki, and interacts with the back-end.
And I know, documentation could be improved :-)


I agree that in some cases the current JS weight of the CORE jspwiki
is to much. Especially imho some of the dynamic styles should not be
part of the core jpswiki package.  I would like to see a kind of
pluggable approach to allow users to add js-pieces they need. (similar
to server side plugins)



dirk

On 8/20/08, Terry Steichen <terry@net-frame.com> wrote:
> I've been wondering for some time if JSPWiki hasn't become somewhat too
> dependent on esoteric Javascript code for its core functionality.  Dirk
> has done a wonderful job - of that, there's absolutely no doubt.  When
> the template logic works (as it normally does quite well), it's a marvel
> to behold.
>
> But when it doesn't, it's sometimes a nightmare to figure out.  I'm OK
> figuring out Java, servlets, HTML and the like - even with its poor
> documentation, I can eventually figure out the innards of JSPWiki code.
> But the increasingly complex Javascript will often does me in.
>
> On Tue, 2008-08-19 at 21:51 +0200, Dirk Frederickx wrote:
>
> > Janne,
> >
> > The 2nd textarea is inserted to allow section-editing.
> > Just 'kill' jspwiki-eidt.js to get rid of it.  (eg. commenting the
> > last line of jspwiki-edit.js will do the trick -- remove
> > window.addEvent ....)
> >
> >
> > dirk
> >
> > On Tue, Aug 19, 2008 at 9:43 PM, Janne Jalkanen
> > <Janne.Jalkanen@ecyrd.com> wrote:
> > >
> > > On 19 Aug 2008, at 22:35, Janne Jalkanen wrote:
> > >
> > >>>
> > >>> Not because of ACLs, but because request.getParameter() is returning
the
> > >>> *page content without edits*.  This should NOT be happening.
> > >>
> > >> Looks like our Javascript is inserting an extraneous <textarea> without
an
> > >> id, and putting the edit content in it.  Ugh.  Hard to debug.
> > >
> > > I would really like to understand what is going on with the editor.  Why are
> > > there two textareas created programmatically?
> > >
> > > /Janne
> > >
>

Mime
View raw message