You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Terry Steichen <te...@net-frame.com> on 2008/08/20 03:42:14 UTC
Javascript jollies (was: weird access rights issue)
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
> <Ja...@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
> >
Re: Javascript jollies (was: weird access rights issue)
Posted by Andrew Jaquith <an...@me.com>.
Selenium would help immensely. During the 2.8 coding cycle, I
refactored the web unit tests so that they would run without any
external dependencies. The rationale was that we needed to make it
easier to create and run web unit tests. Certainly, we can (and
should) use Selenium more to test JavaScript functionality.
The nice thing about Selenium is that you can use the Firefox Selenium-
IDE plugin to "record" the test session. Then, with a little light
editing you can turn it into test that runs as part of the "webtests"
Ant target. See the mostly-accurate docs in tests/etc/selenium/
readme.txt.
The bad thing about Selenium is that it does NOT seem to work with
Firefox 3 yet. However, Firefox 2, IE, Safari etc. seem to work fine.
Regarding the other comments about JavaScript dependencies in JSPWiki,
everyone has made good points so far. I agree that we will need move
certain functions from the client to the server at some point --
ESPECIALLY for any client-side code that manipulates session state. By
"manipulating session state," I MOSTLY mean server-side (JSP, servlet,
core) code whose processing depends on client-supplied cookies.
In the short term, we should probably file JIRA issues as reminders
for things that should be moved.
Andrew
On Aug 20, 2008, at 12:15 PM, Harry Metske wrote:
> The point is that we don't do enough automated testing, it would be
> nice if
> we had some kind of JUnit tests for JS.
> Can the selenium tests do something here ?
> What is the "industry standard" for JS testing ?
>
> I, also like to keep all the goodies of JS in JSPWiki on board, and
> let's
> get to the Stripes release as soon as we can.
>
> regards,
> Harry
>
> 2008/8/20 Janne Jalkanen <Ja...@ecyrd.com>
>
>>
>> On Aug 20, 2008, at 04:42 , Terry Steichen 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.
>>>
>>
>> I think the problem partly stems from the fact that Dirk is the
>> only one
>> doing the JS hacking. With the Java code, it's a shared effort by
>> many
>> people, so it tends to stay readable across for least a few people,
>> which
>> makes it readable to the rest as well.
>>
>> I think we need a few more Javascript hackers ;-)
>>
>> (And also we'll need to think which of the JS functionalities would
>> be
>> better done server-side. For example, I think section editing
>> would be
>> nicer to do server-side, not client-side - for the simple reason
>> that then
>> we could also lock parts of the page, or also be completely
>> collaborative.)
>>
>> /Janne
>>
>
>
>
> --
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081
Re: Javascript jollies (was: weird access rights issue)
Posted by Harry Metske <ha...@gmail.com>.
The point is that we don't do enough automated testing, it would be nice if
we had some kind of JUnit tests for JS.
Can the selenium tests do something here ?
What is the "industry standard" for JS testing ?
I, also like to keep all the goodies of JS in JSPWiki on board, and let's
get to the Stripes release as soon as we can.
regards,
Harry
2008/8/20 Janne Jalkanen <Ja...@ecyrd.com>
>
> On Aug 20, 2008, at 04:42 , Terry Steichen 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.
>>
>
> I think the problem partly stems from the fact that Dirk is the only one
> doing the JS hacking. With the Java code, it's a shared effort by many
> people, so it tends to stay readable across for least a few people, which
> makes it readable to the rest as well.
>
> I think we need a few more Javascript hackers ;-)
>
> (And also we'll need to think which of the JS functionalities would be
> better done server-side. For example, I think section editing would be
> nicer to do server-side, not client-side - for the simple reason that then
> we could also lock parts of the page, or also be completely collaborative.)
>
> /Janne
>
--
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081
Re: Javascript jollies (was: weird access rights issue)
Posted by Florian Holeczek <fl...@holeczek.de>.
Hallo Janne,
> For example, I think section editing would be nicer to do
> server-side, not client-side - for the simple reason that then we
> could also lock parts of the page, or also be completely
> collaborative.)
I think so, too... So you've already found something that isn't
covered by JCR. Who thought that a wiki could become that
sophisticated :-)
Regards
Florian
Re: Javascript jollies (was: weird access rights issue)
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
On Aug 20, 2008, at 04:42 , Terry Steichen 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.
I think the problem partly stems from the fact that Dirk is the only
one doing the JS hacking. With the Java code, it's a shared effort
by many people, so it tends to stay readable across for least a few
people, which makes it readable to the rest as well.
I think we need a few more Javascript hackers ;-)
(And also we'll need to think which of the JS functionalities would
be better done server-side. For example, I think section editing
would be nicer to do server-side, not client-side - for the simple
reason that then we could also lock parts of the page, or also be
completely collaborative.)
/Janne
Re: Javascript jollies (was: weird access rights issue)
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> 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.
Yup, this is exactly correct. As it should be.
>
> And I know, documentation could be improved :-)
I guess this is my gripe. I can see *what* is being done, but not
*why* :-)
> 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)
Yup, we're in agreement here. Of course, adding a lot of small JS
files can have a performance hit when they are loaded from the server
(opening new connections can be expensive). But we could keep them
separate for coding, and then have the build process create a
concatenation.
/Janne
Re: Javascript jollies
Posted by Terry Steichen <te...@net-frame.com>.
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 <te...@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
> > > <Ja...@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
> > > >
> >
Re: Javascript jollies (was: weird access rights issue)
Posted by Dirk Frederickx <di...@gmail.com>.
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 <te...@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
> > <Ja...@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
> > >
>