incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <te...@net-frame.com>
Subject Re: Javascript jollies
Date Wed, 20 Aug 2008 14:00:58 GMT
Dirk,

Good thoughts.  I agree entirely.

Terry

On Wed, 2008-08-20 at 12:44 +0200, Dirk Frederickx wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message