You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Andrew Jaquith <an...@gmail.com> on 2010/02/04 20:43:08 UTC
Seeking Alpha
Hi everybody,
If you've been paying close attention to my recent commits --- and I
*know* you have :) --- you know that I've been putting a lot of energy
around re-working the JSPs. As of last night's checkins, I feel that
most of the goals I set for the 3.0 view layer have been achieved.
Scriptlet code has been moved into the ActionBeans, markup has been
"modernized" with JSTL, and the top-level JSPs have been folded into
the template JSPs. The net result is a set of JSPs that are slimmer,
simpler and better organized. A few stray bugs (notably: JavaScript
and a few URLBinding issues) remain, but the hard work is done.
It is time to turn our sights towards getting an Alpha build out the
door. Here are the current blockers as listed in JIRA:
1. JSPWIKI-303 JSPWiki-API library creation.
2. JSPWIKI-421 JCR backend
3. JSPWIKI-382 Remove posteditor.js
We should make some decisions soon about whether these are really
blockers or not, and figure out what we need to do to close them if
they are.
I'd also propose solving three more issues before we can declare Alpha:
4. Clean unit tests. We still have about 30 renaming, ReferenceManager
and related plugin tests that are failing. I *think* they might be
related to a recent Priha vintage. The build should run clean before
we release an Alpha.
5. URLConstructors. With the physical top-level JSPs gone, we now rely
on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
event. We should do the same for outgoing URL **generation** by making
StripesURLConstructor the default. While we're at it, we should kill
the other URLConstructors, because FileBasedActionResolver will allow
URLBindings to be externally defined. For backwards compatibility,
ShortUrlRedirectFilter allows legacy short URLs to be safely
intercepted and redirected.
6. Refactor WikiBackgroundThread abstract class as JMX timer MBeans.
This would eliminate our somewhat unreliable timer implementation.
Today, background threads don't kill themselves reliably. I take full
responsibility for this, but I also can't fix it easily, and would
rather do it through JMX.
I can do 5 and 6 fairly quickly if we agree to do them.
Are these good priorities for Alpha? What else are we missing?
Andrew
Re: Seeking Alpha
Posted by Andrew Jaquith <an...@gmail.com>.
Murray, I'll try using the 1.2 implementations. Shouldn't be too hard;
a jar swap or two and some URI twiddling. :)
On Feb 5, 2010, at 3:46, Murray Altheim <mu...@altheim.com> wrote:
> Andrew Jaquith wrote:
>> JSPWiki 3 ships with JARs for JSTL 1.1.2, from Apache:
>> jakarta-tablibs-standard-1.1.2.jar
>> jakarta-taglibs-jstl-1.1.2.jar
>> These are the 1.1 versions, which are appropriate for the 2.4 servlet
>> spec that JSPWiki uses, and they are located in WEB-INF/lib. I can't
>> speak about the version problems you've had, but the implementations
>> we ship should be found on the classpath and be the ones that JSPWiki
>> uses.
>> This seems sensible to me. Should we be following a different
>> strategy?
>
> Well, the Jakarta JSTL project has moved from Apache over to Sun, so
> that the JSTL URI identifiers and the jars of 1.1 are incompatible
> with
> JSTL 1.2 code now part of J2EE 5 (much less J2EE 6). We ran into
> problems
> trying to get them to coexist. I think you might reconsider using the
> now-obsolete JSTL 1.1 and migrate to what is now within J2EE itself.
> That
> is, unless we plan to keep JSPWiki tied to the 2.4 spec.
>
> We got caught out by this in that we were using some of the features
> of
> JSTL 1.2 while in development that we didn't notice until we moved to
> our production environment (a good lesson in being certain one's
> dev and prod environments are identical), were forced back to 1.1 for
> compatibility with prod, then will have to deal with the fact that
> we're
> now going to have a forced migration to what we *had* once our
> production
> environment is upgraded. We ended up using scriptlet code in those
> places where we had to remove the JSTL 1.2 features. *sigh*
>
> [I hope the above is clear -- I'm away from my actual documentation on
> this, working from memory.]
>
> Murray
>
> ...
> ...
> .....................................................................
> Murray Altheim <murray09 at altheim dot com>
> === = =
> http://www.altheim.com/murray/ =
> = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
> = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
Re: Seeking Alpha
Posted by Murray Altheim <mu...@altheim.com>.
Andrew Jaquith wrote:
> JSPWiki 3 ships with JARs for JSTL 1.1.2, from Apache:
>
> jakarta-tablibs-standard-1.1.2.jar
> jakarta-taglibs-jstl-1.1.2.jar
>
> These are the 1.1 versions, which are appropriate for the 2.4 servlet
> spec that JSPWiki uses, and they are located in WEB-INF/lib. I can't
> speak about the version problems you've had, but the implementations
> we ship should be found on the classpath and be the ones that JSPWiki
> uses.
>
> This seems sensible to me. Should we be following a different strategy?
Well, the Jakarta JSTL project has moved from Apache over to Sun, so
that the JSTL URI identifiers and the jars of 1.1 are incompatible with
JSTL 1.2 code now part of J2EE 5 (much less J2EE 6). We ran into problems
trying to get them to coexist. I think you might reconsider using the
now-obsolete JSTL 1.1 and migrate to what is now within J2EE itself. That
is, unless we plan to keep JSPWiki tied to the 2.4 spec.
We got caught out by this in that we were using some of the features of
JSTL 1.2 while in development that we didn't notice until we moved to
our production environment (a good lesson in being certain one's
dev and prod environments are identical), were forced back to 1.1 for
compatibility with prod, then will have to deal with the fact that we're
now going to have a forced migration to what we *had* once our production
environment is upgraded. We ended up using scriptlet code in those
places where we had to remove the JSTL 1.2 features. *sigh*
[I hope the above is clear -- I'm away from my actual documentation on
this, working from memory.]
Murray
...........................................................................
Murray Altheim <murray09 at altheim dot com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Seeking Alpha
Posted by Andrew Jaquith <an...@gmail.com>.
JSPWiki 3 ships with JARs for JSTL 1.1.2, from Apache:
jakarta-tablibs-standard-1.1.2.jar
jakarta-taglibs-jstl-1.1.2.jar
These are the 1.1 versions, which are appropriate for the 2.4 servlet
spec that JSPWiki uses, and they are located in WEB-INF/lib. I can't
speak about the version problems you've had, but the implementations
we ship should be found on the classpath and be the ones that JSPWiki
uses.
This seems sensible to me. Should we be following a different strategy?
Andrew
On Thu, Feb 4, 2010 at 3:59 PM, Murray Altheim <mu...@altheim.com> wrote:
> Andrew Jaquith wrote:
>>
>> Hi everybody,
>>
>> If you've been paying close attention to my recent commits --- and I
>> *know* you have :) --- you know that I've been putting a lot of energy
>> around re-working the JSPs. As of last night's checkins, I feel that
>> most of the goals I set for the 3.0 view layer have been achieved.
>> Scriptlet code has been moved into the ActionBeans, markup has been
>> "modernized" with JSTL, and the top-level JSPs have been folded into
>> the template JSPs. The net result is a set of JSPs that are slimmer,
>> simpler and better organized. A few stray bugs (notably: JavaScript
>> and a few URLBinding issues) remain, but the hard work is done.
>
> [...]
>>
>> We should make some decisions soon about whether these are really
>> blockers or not, and figure out what we need to do to close them if
>> they are.
>
> Hi Andrew,
>
> I would like to ask a preliminary question, as I'm guessing you have a
> good answer to it. In my experience we've had a number of issues with
> JSTL, namely version compatibility. We've had situations where the
> version chosen for development wasn't compatible with our production
> environment, and JSTL URI identifiers seem more the problem than the
> actual markup itself. This has made JSTL a very unstable platform for
> our development work, and we've had to coordinate carefully with our
> IT team to make sure we were installing all the right versions in order
> to avoid this. There was no problem with JSPs or scriptlets but as soon
> as we began using JSTL all hell broke loose.
>
> Could you *briefly* describe how you've avoided this for JSPWiki?
>
> Thanks much,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray09 at altheim dot com> === = =
> http://www.altheim.com/murray/ = = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
>
Re: Seeking Alpha
Posted by Murray Altheim <mu...@altheim.com>.
Andrew Jaquith wrote:
> Hi everybody,
>
> If you've been paying close attention to my recent commits --- and I
> *know* you have :) --- you know that I've been putting a lot of energy
> around re-working the JSPs. As of last night's checkins, I feel that
> most of the goals I set for the 3.0 view layer have been achieved.
> Scriptlet code has been moved into the ActionBeans, markup has been
> "modernized" with JSTL, and the top-level JSPs have been folded into
> the template JSPs. The net result is a set of JSPs that are slimmer,
> simpler and better organized. A few stray bugs (notably: JavaScript
> and a few URLBinding issues) remain, but the hard work is done.
[...]
> We should make some decisions soon about whether these are really
> blockers or not, and figure out what we need to do to close them if
> they are.
Hi Andrew,
I would like to ask a preliminary question, as I'm guessing you have a
good answer to it. In my experience we've had a number of issues with
JSTL, namely version compatibility. We've had situations where the
version chosen for development wasn't compatible with our production
environment, and JSTL URI identifiers seem more the problem than the
actual markup itself. This has made JSTL a very unstable platform for
our development work, and we've had to coordinate carefully with our
IT team to make sure we were installing all the right versions in order
to avoid this. There was no problem with JSPs or scriptlets but as soon
as we began using JSTL all hell broke loose.
Could you *briefly* describe how you've avoided this for JSPWiki?
Thanks much,
Murray
...........................................................................
Murray Altheim <murray09 at altheim dot com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: Seeking Alpha
Posted by Andrew Jaquith <an...@gmail.com>.
Dirk,
The culprit on the double-submit Javascript issues appears to be with
the snip-editor. If you use a non-existent textarea variable name in
line 61 in jspwiki-edit.js (part of var WikEdit), for example:
var txta = $('wikiTexts'),
...then the problem goes away. This is blunt fix, not a permanent one.
I suspect the root cause is this section, which comes later in the file:
.addEvent('change', self.onChangeTXTA.bind( self ) );
// Make sure to catch ALL {{change}} events, and copy the
// content of txta back to the main textarea.
// This includes the ''last'' change event, just before firing
// the submit event of the form.
But I am not a JavaScript guru, and don't know how to really fix this.
If/when you get your webapp running, this is probably what needs
fixing.
In the meantime, I'll upload the temporary fix later today. (I'll also
do a little light housecleaning, such removal of the sneak-preview JS
code, which is made redundant with the new Strips preview AJAX calls.)
Andrew
On Sun, Feb 14, 2010 at 7:03 PM, Andrew Jaquith
<an...@gmail.com> wrote:
> Hi all -- with the most recent checkins, I knocked #5 and #6 off the list.
> So, the WikiBackgroundThreads are now JMX-triggered classes. And
> StripesURLConstructor is now the default (and only allowed) URLConstructor.
> Amazingly, after I eliminated one dumb bug, it passed 198 out of 200
> JSPWikiMarkupParser tests. (Two pesky Scandic tests aren't passing...)
>
> I'll focus next on eliminating the 55 or so failing tests, and possibly the
> JSON death issue.
>
> Andrew
>
> On Feb 7, 2010, at 16:58, Dirk Frederickx <di...@gmail.com> wrote:
>
>> The improvements on the .jsp's are cool, and really a simplification !
>> Stripes is really a big improv.
>> I just need to find the time to catch up with most of your changes.
>> In parallel I'm making some js enhancements, especially on the editor
>> front.
>>
>> But currently I have no working environment, so it's hard to start tracing
>> and fixing stuff.
>>
>>
>> dirk
>>
>>
>>
>> On Sun, Feb 7, 2010 at 10:41 PM, Andrew Jaquith
>> <an...@gmail.com>wrote:
>>
>>> Thanks, Dirk!
>>>
>>> I understand what you mean about the changes to the templates But the
>>> templates are finally done. I don't expect them to change much more. The
>>> most difficult work is behind us.
>>>
>>> If ypu think it would speed things along, we could have a quick call
>>> (iChat?) about the Javascript issues.
>>>
>>> Andrew
>>>
>>>
>>> On Feb 7, 2010, at 13:12, Dirk Frederickx <di...@gmail.com>
>>> wrote:
>>>
>>> Andrew,
>>>>
>>>> A bunch of javascript updates are waiting for check-in.
>>>> The speed at which the template is changing is hard to follow ;-)
>>>>
>>>> Currently, I'm blocked with deploy issues -- hope this can be fixed
>>>> soon.
>>>>
>>>>
>>>>
>>>> JSPWIKI-382 can be closed soon: posteditor.js is already not used
>>>> anymore;
>>>> but the new plain editor is still buggy.
>>>>
>>>>
>>>>
>>>> dirk
>>>>
>>>> On Sat, Feb 6, 2010 at 4:36 PM, Andrew Jaquith
>>>> <an...@gmail.com>wrote:
>>>>
>>>> Harry, thanks for the kind words!
>>>>>
>>>>> The first two issues are good ones that we should fix. +1. Good catch!
>>>>> Note
>>>>> that the JSON search needs to be rewired to use the Stripes calls.
>>>>> Ultimately we want to get rid of the JSON bridge and just call the
>>>>> event
>>>>> URLs directly.
>>>>>
>>>>> Not sure we need to do web unit tests just yet. Definitely for beta
>>>>> though!
>>>>>
>>>>> Andrew
>>>>>
>>>>>
>>>>> On Feb 5, 2010, at 9:30, Harry Metske <ha...@gmail.com> wrote:
>>>>>
>>>>> Andrew,
>>>>>
>>>>>>
>>>>>> first I want to express my appreciation for the huge contribution
>>>>>> you've
>>>>>> made, we should have more people on the team like you.
>>>>>> Now the issues, I can agree on all 6 issues, and want to suggest we
>>>>>> add
>>>>>> the
>>>>>> following to them assuming we want an Alpha JSPWiki that works for
>>>>>> basic
>>>>>> functions like page editing, saving, and so on.
>>>>>>
>>>>>> - There is still the "page edit concatenation" problem (no JIRA issue
>>>>>> yet,
>>>>>> but I can create one)
>>>>>> - JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not honor
>>>>>> ACLs
>>>>>> (security is important for the ASF and for ourselves)
>>>>>> - not quite sure if we should also first try to get the webtests
>>>>>> (Selenium
>>>>>> or an alternative?) up and running
>>>>>>
>>>>>> One of the things I can help with is fixing the unit tests I think.
>>>>>>
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>> 2010/2/4 Andrew Jaquith <an...@gmail.com>
>>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>>>
>>>>>>> If you've been paying close attention to my recent commits --- and I
>>>>>>> *know* you have :) --- you know that I've been putting a lot of
>>>>>>> energy
>>>>>>> around re-working the JSPs. As of last night's checkins, I feel that
>>>>>>> most of the goals I set for the 3.0 view layer have been achieved.
>>>>>>> Scriptlet code has been moved into the ActionBeans, markup has been
>>>>>>> "modernized" with JSTL, and the top-level JSPs have been folded into
>>>>>>> the template JSPs. The net result is a set of JSPs that are slimmer,
>>>>>>> simpler and better organized. A few stray bugs (notably: JavaScript
>>>>>>> and a few URLBinding issues) remain, but the hard work is done.
>>>>>>>
>>>>>>> It is time to turn our sights towards getting an Alpha build out the
>>>>>>> door. Here are the current blockers as listed in JIRA:
>>>>>>>
>>>>>>> 1. JSPWIKI-303 JSPWiki-API library creation.
>>>>>>> 2. JSPWIKI-421 JCR backend
>>>>>>> 3. JSPWIKI-382 Remove posteditor.js
>>>>>>>
>>>>>>> We should make some decisions soon about whether these are really
>>>>>>> blockers or not, and figure out what we need to do to close them if
>>>>>>> they are.
>>>>>>>
>>>>>>> I'd also propose solving three more issues before we can declare
>>>>>>> Alpha:
>>>>>>>
>>>>>>> 4. Clean unit tests. We still have about 30 renaming,
>>>>>>> ReferenceManager
>>>>>>> and related plugin tests that are failing. I *think* they might be
>>>>>>> related to a recent Priha vintage. The build should run clean before
>>>>>>> we release an Alpha.
>>>>>>>
>>>>>>> 5. URLConstructors. With the physical top-level JSPs gone, we now
>>>>>>> rely
>>>>>>> on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
>>>>>>> event. We should do the same for outgoing URL **generation** by
>>>>>>> making
>>>>>>> StripesURLConstructor the default. While we're at it, we should kill
>>>>>>> the other URLConstructors, because FileBasedActionResolver will allow
>>>>>>> URLBindings to be externally defined. For backwards compatibility,
>>>>>>> ShortUrlRedirectFilter allows legacy short URLs to be safely
>>>>>>> intercepted and redirected.
>>>>>>>
>>>>>>> 6. Refactor WikiBackgroundThread abstract class as JMX timer MBeans.
>>>>>>> This would eliminate our somewhat unreliable timer implementation.
>>>>>>> Today, background threads don't kill themselves reliably. I take full
>>>>>>> responsibility for this, but I also can't fix it easily, and would
>>>>>>> rather do it through JMX.
>>>>>>>
>>>>>>> I can do 5 and 6 fairly quickly if we agree to do them.
>>>>>>>
>>>>>>> Are these good priorities for Alpha? What else are we missing?
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Seeking Alpha
Posted by Andrew Jaquith <an...@gmail.com>.
Hi all -- with the most recent checkins, I knocked #5 and #6 off the
list. So, the WikiBackgroundThreads are now JMX-triggered classes. And
StripesURLConstructor is now the default (and only allowed)
URLConstructor. Amazingly, after I eliminated one dumb bug, it passed
198 out of 200 JSPWikiMarkupParser tests. (Two pesky Scandic tests
aren't passing...)
I'll focus next on eliminating the 55 or so failing tests, and
possibly the JSON death issue.
Andrew
On Feb 7, 2010, at 16:58, Dirk Frederickx <di...@gmail.com>
wrote:
> The improvements on the .jsp's are cool, and really a simplification !
> Stripes is really a big improv.
> I just need to find the time to catch up with most of your changes.
> In parallel I'm making some js enhancements, especially on the
> editor front.
>
> But currently I have no working environment, so it's hard to start
> tracing
> and fixing stuff.
>
>
> dirk
>
>
>
> On Sun, Feb 7, 2010 at 10:41 PM, Andrew Jaquith
> <an...@gmail.com>wrote:
>
>> Thanks, Dirk!
>>
>> I understand what you mean about the changes to the templates But
>> the
>> templates are finally done. I don't expect them to change much
>> more. The
>> most difficult work is behind us.
>>
>> If ypu think it would speed things along, we could have a quick call
>> (iChat?) about the Javascript issues.
>>
>> Andrew
>>
>>
>> On Feb 7, 2010, at 13:12, Dirk Frederickx <di...@gmail.com>
>> wrote:
>>
>> Andrew,
>>>
>>> A bunch of javascript updates are waiting for check-in.
>>> The speed at which the template is changing is hard to follow ;-)
>>>
>>> Currently, I'm blocked with deploy issues -- hope this can be
>>> fixed soon.
>>>
>>>
>>>
>>> JSPWIKI-382 can be closed soon: posteditor.js is already not used
>>> anymore;
>>> but the new plain editor is still buggy.
>>>
>>>
>>>
>>> dirk
>>>
>>> On Sat, Feb 6, 2010 at 4:36 PM, Andrew Jaquith
>>> <an...@gmail.com>wrote:
>>>
>>> Harry, thanks for the kind words!
>>>>
>>>> The first two issues are good ones that we should fix. +1. Good
>>>> catch!
>>>> Note
>>>> that the JSON search needs to be rewired to use the Stripes calls.
>>>> Ultimately we want to get rid of the JSON bridge and just call
>>>> the event
>>>> URLs directly.
>>>>
>>>> Not sure we need to do web unit tests just yet. Definitely for beta
>>>> though!
>>>>
>>>> Andrew
>>>>
>>>>
>>>> On Feb 5, 2010, at 9:30, Harry Metske <ha...@gmail.com>
>>>> wrote:
>>>>
>>>> Andrew,
>>>>
>>>>>
>>>>> first I want to express my appreciation for the huge
>>>>> contribution you've
>>>>> made, we should have more people on the team like you.
>>>>> Now the issues, I can agree on all 6 issues, and want to suggest
>>>>> we add
>>>>> the
>>>>> following to them assuming we want an Alpha JSPWiki that works
>>>>> for basic
>>>>> functions like page editing, saving, and so on.
>>>>>
>>>>> - There is still the "page edit concatenation" problem (no JIRA
>>>>> issue
>>>>> yet,
>>>>> but I can create one)
>>>>> - JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not
>>>>> honor ACLs
>>>>> (security is important for the ASF and for ourselves)
>>>>> - not quite sure if we should also first try to get the webtests
>>>>> (Selenium
>>>>> or an alternative?) up and running
>>>>>
>>>>> One of the things I can help with is fixing the unit tests I
>>>>> think.
>>>>>
>>>>> regards,
>>>>> Harry
>>>>>
>>>>> 2010/2/4 Andrew Jaquith <an...@gmail.com>
>>>>>
>>>>> Hi everybody,
>>>>>
>>>>>>
>>>>>> If you've been paying close attention to my recent commits ---
>>>>>> and I
>>>>>> *know* you have :) --- you know that I've been putting a lot of
>>>>>> energy
>>>>>> around re-working the JSPs. As of last night's checkins, I feel
>>>>>> that
>>>>>> most of the goals I set for the 3.0 view layer have been
>>>>>> achieved.
>>>>>> Scriptlet code has been moved into the ActionBeans, markup has
>>>>>> been
>>>>>> "modernized" with JSTL, and the top-level JSPs have been folded
>>>>>> into
>>>>>> the template JSPs. The net result is a set of JSPs that are
>>>>>> slimmer,
>>>>>> simpler and better organized. A few stray bugs (notably:
>>>>>> JavaScript
>>>>>> and a few URLBinding issues) remain, but the hard work is done.
>>>>>>
>>>>>> It is time to turn our sights towards getting an Alpha build
>>>>>> out the
>>>>>> door. Here are the current blockers as listed in JIRA:
>>>>>>
>>>>>> 1. JSPWIKI-303 JSPWiki-API library creation.
>>>>>> 2. JSPWIKI-421 JCR backend
>>>>>> 3. JSPWIKI-382 Remove posteditor.js
>>>>>>
>>>>>> We should make some decisions soon about whether these are really
>>>>>> blockers or not, and figure out what we need to do to close
>>>>>> them if
>>>>>> they are.
>>>>>>
>>>>>> I'd also propose solving three more issues before we can
>>>>>> declare Alpha:
>>>>>>
>>>>>> 4. Clean unit tests. We still have about 30 renaming,
>>>>>> ReferenceManager
>>>>>> and related plugin tests that are failing. I *think* they might
>>>>>> be
>>>>>> related to a recent Priha vintage. The build should run clean
>>>>>> before
>>>>>> we release an Alpha.
>>>>>>
>>>>>> 5. URLConstructors. With the physical top-level JSPs gone, we
>>>>>> now rely
>>>>>> on Stripes URLBindings to map incoming *.jsp resquests to
>>>>>> ActionBean
>>>>>> event. We should do the same for outgoing URL **generation** by
>>>>>> making
>>>>>> StripesURLConstructor the default. While we're at it, we should
>>>>>> kill
>>>>>> the other URLConstructors, because FileBasedActionResolver will
>>>>>> allow
>>>>>> URLBindings to be externally defined. For backwards
>>>>>> compatibility,
>>>>>> ShortUrlRedirectFilter allows legacy short URLs to be safely
>>>>>> intercepted and redirected.
>>>>>>
>>>>>> 6. Refactor WikiBackgroundThread abstract class as JMX timer
>>>>>> MBeans.
>>>>>> This would eliminate our somewhat unreliable timer
>>>>>> implementation.
>>>>>> Today, background threads don't kill themselves reliably. I
>>>>>> take full
>>>>>> responsibility for this, but I also can't fix it easily, and
>>>>>> would
>>>>>> rather do it through JMX.
>>>>>>
>>>>>> I can do 5 and 6 fairly quickly if we agree to do them.
>>>>>>
>>>>>> Are these good priorities for Alpha? What else are we missing?
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>>
Re: Seeking Alpha
Posted by Dirk Frederickx <di...@gmail.com>.
The improvements on the .jsp's are cool, and really a simplification !
Stripes is really a big improv.
I just need to find the time to catch up with most of your changes.
In parallel I'm making some js enhancements, especially on the editor front.
But currently I have no working environment, so it's hard to start tracing
and fixing stuff.
dirk
On Sun, Feb 7, 2010 at 10:41 PM, Andrew Jaquith
<an...@gmail.com>wrote:
> Thanks, Dirk!
>
> I understand what you mean about the changes to the templates But the
> templates are finally done. I don't expect them to change much more. The
> most difficult work is behind us.
>
> If ypu think it would speed things along, we could have a quick call
> (iChat?) about the Javascript issues.
>
> Andrew
>
>
> On Feb 7, 2010, at 13:12, Dirk Frederickx <di...@gmail.com>
> wrote:
>
> Andrew,
>>
>> A bunch of javascript updates are waiting for check-in.
>> The speed at which the template is changing is hard to follow ;-)
>>
>> Currently, I'm blocked with deploy issues -- hope this can be fixed soon.
>>
>>
>>
>> JSPWIKI-382 can be closed soon: posteditor.js is already not used anymore;
>> but the new plain editor is still buggy.
>>
>>
>>
>> dirk
>>
>> On Sat, Feb 6, 2010 at 4:36 PM, Andrew Jaquith
>> <an...@gmail.com>wrote:
>>
>> Harry, thanks for the kind words!
>>>
>>> The first two issues are good ones that we should fix. +1. Good catch!
>>> Note
>>> that the JSON search needs to be rewired to use the Stripes calls.
>>> Ultimately we want to get rid of the JSON bridge and just call the event
>>> URLs directly.
>>>
>>> Not sure we need to do web unit tests just yet. Definitely for beta
>>> though!
>>>
>>> Andrew
>>>
>>>
>>> On Feb 5, 2010, at 9:30, Harry Metske <ha...@gmail.com> wrote:
>>>
>>> Andrew,
>>>
>>>>
>>>> first I want to express my appreciation for the huge contribution you've
>>>> made, we should have more people on the team like you.
>>>> Now the issues, I can agree on all 6 issues, and want to suggest we add
>>>> the
>>>> following to them assuming we want an Alpha JSPWiki that works for basic
>>>> functions like page editing, saving, and so on.
>>>>
>>>> - There is still the "page edit concatenation" problem (no JIRA issue
>>>> yet,
>>>> but I can create one)
>>>> - JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not honor ACLs
>>>> (security is important for the ASF and for ourselves)
>>>> - not quite sure if we should also first try to get the webtests
>>>> (Selenium
>>>> or an alternative?) up and running
>>>>
>>>> One of the things I can help with is fixing the unit tests I think.
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2010/2/4 Andrew Jaquith <an...@gmail.com>
>>>>
>>>> Hi everybody,
>>>>
>>>>>
>>>>> If you've been paying close attention to my recent commits --- and I
>>>>> *know* you have :) --- you know that I've been putting a lot of energy
>>>>> around re-working the JSPs. As of last night's checkins, I feel that
>>>>> most of the goals I set for the 3.0 view layer have been achieved.
>>>>> Scriptlet code has been moved into the ActionBeans, markup has been
>>>>> "modernized" with JSTL, and the top-level JSPs have been folded into
>>>>> the template JSPs. The net result is a set of JSPs that are slimmer,
>>>>> simpler and better organized. A few stray bugs (notably: JavaScript
>>>>> and a few URLBinding issues) remain, but the hard work is done.
>>>>>
>>>>> It is time to turn our sights towards getting an Alpha build out the
>>>>> door. Here are the current blockers as listed in JIRA:
>>>>>
>>>>> 1. JSPWIKI-303 JSPWiki-API library creation.
>>>>> 2. JSPWIKI-421 JCR backend
>>>>> 3. JSPWIKI-382 Remove posteditor.js
>>>>>
>>>>> We should make some decisions soon about whether these are really
>>>>> blockers or not, and figure out what we need to do to close them if
>>>>> they are.
>>>>>
>>>>> I'd also propose solving three more issues before we can declare Alpha:
>>>>>
>>>>> 4. Clean unit tests. We still have about 30 renaming, ReferenceManager
>>>>> and related plugin tests that are failing. I *think* they might be
>>>>> related to a recent Priha vintage. The build should run clean before
>>>>> we release an Alpha.
>>>>>
>>>>> 5. URLConstructors. With the physical top-level JSPs gone, we now rely
>>>>> on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
>>>>> event. We should do the same for outgoing URL **generation** by making
>>>>> StripesURLConstructor the default. While we're at it, we should kill
>>>>> the other URLConstructors, because FileBasedActionResolver will allow
>>>>> URLBindings to be externally defined. For backwards compatibility,
>>>>> ShortUrlRedirectFilter allows legacy short URLs to be safely
>>>>> intercepted and redirected.
>>>>>
>>>>> 6. Refactor WikiBackgroundThread abstract class as JMX timer MBeans.
>>>>> This would eliminate our somewhat unreliable timer implementation.
>>>>> Today, background threads don't kill themselves reliably. I take full
>>>>> responsibility for this, but I also can't fix it easily, and would
>>>>> rather do it through JMX.
>>>>>
>>>>> I can do 5 and 6 fairly quickly if we agree to do them.
>>>>>
>>>>> Are these good priorities for Alpha? What else are we missing?
>>>>>
>>>>> Andrew
>>>>>
>>>>>
>>>>>
Re: Seeking Alpha
Posted by Andrew Jaquith <an...@gmail.com>.
Thanks, Dirk!
I understand what you mean about the changes to the templates But the
templates are finally done. I don't expect them to change much more.
The most difficult work is behind us.
If ypu think it would speed things along, we could have a quick call
(iChat?) about the Javascript issues.
Andrew
On Feb 7, 2010, at 13:12, Dirk Frederickx <di...@gmail.com>
wrote:
> Andrew,
>
> A bunch of javascript updates are waiting for check-in.
> The speed at which the template is changing is hard to follow ;-)
>
> Currently, I'm blocked with deploy issues -- hope this can be fixed
> soon.
>
>
>
> JSPWIKI-382 can be closed soon: posteditor.js is already not used
> anymore;
> but the new plain editor is still buggy.
>
>
>
> dirk
>
> On Sat, Feb 6, 2010 at 4:36 PM, Andrew Jaquith
> <an...@gmail.com>wrote:
>
>> Harry, thanks for the kind words!
>>
>> The first two issues are good ones that we should fix. +1. Good
>> catch! Note
>> that the JSON search needs to be rewired to use the Stripes calls.
>> Ultimately we want to get rid of the JSON bridge and just call the
>> event
>> URLs directly.
>>
>> Not sure we need to do web unit tests just yet. Definitely for beta
>> though!
>>
>> Andrew
>>
>>
>> On Feb 5, 2010, at 9:30, Harry Metske <ha...@gmail.com> wrote:
>>
>> Andrew,
>>>
>>> first I want to express my appreciation for the huge contribution
>>> you've
>>> made, we should have more people on the team like you.
>>> Now the issues, I can agree on all 6 issues, and want to suggest
>>> we add
>>> the
>>> following to them assuming we want an Alpha JSPWiki that works for
>>> basic
>>> functions like page editing, saving, and so on.
>>>
>>> - There is still the "page edit concatenation" problem (no JIRA
>>> issue yet,
>>> but I can create one)
>>> - JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not
>>> honor ACLs
>>> (security is important for the ASF and for ourselves)
>>> - not quite sure if we should also first try to get the webtests
>>> (Selenium
>>> or an alternative?) up and running
>>>
>>> One of the things I can help with is fixing the unit tests I think.
>>>
>>> regards,
>>> Harry
>>>
>>> 2010/2/4 Andrew Jaquith <an...@gmail.com>
>>>
>>> Hi everybody,
>>>>
>>>> If you've been paying close attention to my recent commits ---
>>>> and I
>>>> *know* you have :) --- you know that I've been putting a lot of
>>>> energy
>>>> around re-working the JSPs. As of last night's checkins, I feel
>>>> that
>>>> most of the goals I set for the 3.0 view layer have been achieved.
>>>> Scriptlet code has been moved into the ActionBeans, markup has been
>>>> "modernized" with JSTL, and the top-level JSPs have been folded
>>>> into
>>>> the template JSPs. The net result is a set of JSPs that are
>>>> slimmer,
>>>> simpler and better organized. A few stray bugs (notably: JavaScript
>>>> and a few URLBinding issues) remain, but the hard work is done.
>>>>
>>>> It is time to turn our sights towards getting an Alpha build out
>>>> the
>>>> door. Here are the current blockers as listed in JIRA:
>>>>
>>>> 1. JSPWIKI-303 JSPWiki-API library creation.
>>>> 2. JSPWIKI-421 JCR backend
>>>> 3. JSPWIKI-382 Remove posteditor.js
>>>>
>>>> We should make some decisions soon about whether these are really
>>>> blockers or not, and figure out what we need to do to close them if
>>>> they are.
>>>>
>>>> I'd also propose solving three more issues before we can declare
>>>> Alpha:
>>>>
>>>> 4. Clean unit tests. We still have about 30 renaming,
>>>> ReferenceManager
>>>> and related plugin tests that are failing. I *think* they might be
>>>> related to a recent Priha vintage. The build should run clean
>>>> before
>>>> we release an Alpha.
>>>>
>>>> 5. URLConstructors. With the physical top-level JSPs gone, we now
>>>> rely
>>>> on Stripes URLBindings to map incoming *.jsp resquests to
>>>> ActionBean
>>>> event. We should do the same for outgoing URL **generation** by
>>>> making
>>>> StripesURLConstructor the default. While we're at it, we should
>>>> kill
>>>> the other URLConstructors, because FileBasedActionResolver will
>>>> allow
>>>> URLBindings to be externally defined. For backwards compatibility,
>>>> ShortUrlRedirectFilter allows legacy short URLs to be safely
>>>> intercepted and redirected.
>>>>
>>>> 6. Refactor WikiBackgroundThread abstract class as JMX timer
>>>> MBeans.
>>>> This would eliminate our somewhat unreliable timer implementation.
>>>> Today, background threads don't kill themselves reliably. I take
>>>> full
>>>> responsibility for this, but I also can't fix it easily, and would
>>>> rather do it through JMX.
>>>>
>>>> I can do 5 and 6 fairly quickly if we agree to do them.
>>>>
>>>> Are these good priorities for Alpha? What else are we missing?
>>>>
>>>> Andrew
>>>>
>>>>
Re: Seeking Alpha
Posted by Dirk Frederickx <di...@gmail.com>.
Andrew,
A bunch of javascript updates are waiting for check-in.
The speed at which the template is changing is hard to follow ;-)
Currently, I'm blocked with deploy issues -- hope this can be fixed soon.
JSPWIKI-382 can be closed soon: posteditor.js is already not used anymore;
but the new plain editor is still buggy.
dirk
On Sat, Feb 6, 2010 at 4:36 PM, Andrew Jaquith
<an...@gmail.com>wrote:
> Harry, thanks for the kind words!
>
> The first two issues are good ones that we should fix. +1. Good catch! Note
> that the JSON search needs to be rewired to use the Stripes calls.
> Ultimately we want to get rid of the JSON bridge and just call the event
> URLs directly.
>
> Not sure we need to do web unit tests just yet. Definitely for beta though!
>
> Andrew
>
>
> On Feb 5, 2010, at 9:30, Harry Metske <ha...@gmail.com> wrote:
>
> Andrew,
>>
>> first I want to express my appreciation for the huge contribution you've
>> made, we should have more people on the team like you.
>> Now the issues, I can agree on all 6 issues, and want to suggest we add
>> the
>> following to them assuming we want an Alpha JSPWiki that works for basic
>> functions like page editing, saving, and so on.
>>
>> - There is still the "page edit concatenation" problem (no JIRA issue yet,
>> but I can create one)
>> - JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not honor ACLs
>> (security is important for the ASF and for ourselves)
>> - not quite sure if we should also first try to get the webtests (Selenium
>> or an alternative?) up and running
>>
>> One of the things I can help with is fixing the unit tests I think.
>>
>> regards,
>> Harry
>>
>> 2010/2/4 Andrew Jaquith <an...@gmail.com>
>>
>> Hi everybody,
>>>
>>> If you've been paying close attention to my recent commits --- and I
>>> *know* you have :) --- you know that I've been putting a lot of energy
>>> around re-working the JSPs. As of last night's checkins, I feel that
>>> most of the goals I set for the 3.0 view layer have been achieved.
>>> Scriptlet code has been moved into the ActionBeans, markup has been
>>> "modernized" with JSTL, and the top-level JSPs have been folded into
>>> the template JSPs. The net result is a set of JSPs that are slimmer,
>>> simpler and better organized. A few stray bugs (notably: JavaScript
>>> and a few URLBinding issues) remain, but the hard work is done.
>>>
>>> It is time to turn our sights towards getting an Alpha build out the
>>> door. Here are the current blockers as listed in JIRA:
>>>
>>> 1. JSPWIKI-303 JSPWiki-API library creation.
>>> 2. JSPWIKI-421 JCR backend
>>> 3. JSPWIKI-382 Remove posteditor.js
>>>
>>> We should make some decisions soon about whether these are really
>>> blockers or not, and figure out what we need to do to close them if
>>> they are.
>>>
>>> I'd also propose solving three more issues before we can declare Alpha:
>>>
>>> 4. Clean unit tests. We still have about 30 renaming, ReferenceManager
>>> and related plugin tests that are failing. I *think* they might be
>>> related to a recent Priha vintage. The build should run clean before
>>> we release an Alpha.
>>>
>>> 5. URLConstructors. With the physical top-level JSPs gone, we now rely
>>> on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
>>> event. We should do the same for outgoing URL **generation** by making
>>> StripesURLConstructor the default. While we're at it, we should kill
>>> the other URLConstructors, because FileBasedActionResolver will allow
>>> URLBindings to be externally defined. For backwards compatibility,
>>> ShortUrlRedirectFilter allows legacy short URLs to be safely
>>> intercepted and redirected.
>>>
>>> 6. Refactor WikiBackgroundThread abstract class as JMX timer MBeans.
>>> This would eliminate our somewhat unreliable timer implementation.
>>> Today, background threads don't kill themselves reliably. I take full
>>> responsibility for this, but I also can't fix it easily, and would
>>> rather do it through JMX.
>>>
>>> I can do 5 and 6 fairly quickly if we agree to do them.
>>>
>>> Are these good priorities for Alpha? What else are we missing?
>>>
>>> Andrew
>>>
>>>
Re: Seeking Alpha
Posted by Andrew Jaquith <an...@gmail.com>.
Harry, thanks for the kind words!
The first two issues are good ones that we should fix. +1. Good catch!
Note that the JSON search needs to be rewired to use the Stripes
calls. Ultimately we want to get rid of the JSON bridge and just call
the event URLs directly.
Not sure we need to do web unit tests just yet. Definitely for beta
though!
Andrew
On Feb 5, 2010, at 9:30, Harry Metske <ha...@gmail.com> wrote:
> Andrew,
>
> first I want to express my appreciation for the huge contribution
> you've
> made, we should have more people on the team like you.
> Now the issues, I can agree on all 6 issues, and want to suggest we
> add the
> following to them assuming we want an Alpha JSPWiki that works for
> basic
> functions like page editing, saving, and so on.
>
> - There is still the "page edit concatenation" problem (no JIRA
> issue yet,
> but I can create one)
> - JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not honor
> ACLs
> (security is important for the ASF and for ourselves)
> - not quite sure if we should also first try to get the webtests
> (Selenium
> or an alternative?) up and running
>
> One of the things I can help with is fixing the unit tests I think.
>
> regards,
> Harry
>
> 2010/2/4 Andrew Jaquith <an...@gmail.com>
>
>> Hi everybody,
>>
>> If you've been paying close attention to my recent commits --- and I
>> *know* you have :) --- you know that I've been putting a lot of
>> energy
>> around re-working the JSPs. As of last night's checkins, I feel that
>> most of the goals I set for the 3.0 view layer have been achieved.
>> Scriptlet code has been moved into the ActionBeans, markup has been
>> "modernized" with JSTL, and the top-level JSPs have been folded into
>> the template JSPs. The net result is a set of JSPs that are slimmer,
>> simpler and better organized. A few stray bugs (notably: JavaScript
>> and a few URLBinding issues) remain, but the hard work is done.
>>
>> It is time to turn our sights towards getting an Alpha build out the
>> door. Here are the current blockers as listed in JIRA:
>>
>> 1. JSPWIKI-303 JSPWiki-API library creation.
>> 2. JSPWIKI-421 JCR backend
>> 3. JSPWIKI-382 Remove posteditor.js
>>
>> We should make some decisions soon about whether these are really
>> blockers or not, and figure out what we need to do to close them if
>> they are.
>>
>> I'd also propose solving three more issues before we can declare
>> Alpha:
>>
>> 4. Clean unit tests. We still have about 30 renaming,
>> ReferenceManager
>> and related plugin tests that are failing. I *think* they might be
>> related to a recent Priha vintage. The build should run clean before
>> we release an Alpha.
>>
>> 5. URLConstructors. With the physical top-level JSPs gone, we now
>> rely
>> on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
>> event. We should do the same for outgoing URL **generation** by
>> making
>> StripesURLConstructor the default. While we're at it, we should kill
>> the other URLConstructors, because FileBasedActionResolver will allow
>> URLBindings to be externally defined. For backwards compatibility,
>> ShortUrlRedirectFilter allows legacy short URLs to be safely
>> intercepted and redirected.
>>
>> 6. Refactor WikiBackgroundThread abstract class as JMX timer MBeans.
>> This would eliminate our somewhat unreliable timer implementation.
>> Today, background threads don't kill themselves reliably. I take full
>> responsibility for this, but I also can't fix it easily, and would
>> rather do it through JMX.
>>
>> I can do 5 and 6 fairly quickly if we agree to do them.
>>
>> Are these good priorities for Alpha? What else are we missing?
>>
>> Andrew
>>
Re: Seeking Alpha
Posted by Harry Metske <ha...@gmail.com>.
Andrew,
first I want to express my appreciation for the huge contribution you've
made, we should have more people on the team like you.
Now the issues, I can agree on all 6 issues, and want to suggest we add the
following to them assuming we want an Alpha JSPWiki that works for basic
functions like page editing, saving, and so on.
- There is still the "page edit concatenation" problem (no JIRA issue yet,
but I can create one)
- JSPWIKI-510 - SearchManager.JSONSearch.findPages() does not honor ACLs
(security is important for the ASF and for ourselves)
- not quite sure if we should also first try to get the webtests (Selenium
or an alternative?) up and running
One of the things I can help with is fixing the unit tests I think.
regards,
Harry
2010/2/4 Andrew Jaquith <an...@gmail.com>
> Hi everybody,
>
> If you've been paying close attention to my recent commits --- and I
> *know* you have :) --- you know that I've been putting a lot of energy
> around re-working the JSPs. As of last night's checkins, I feel that
> most of the goals I set for the 3.0 view layer have been achieved.
> Scriptlet code has been moved into the ActionBeans, markup has been
> "modernized" with JSTL, and the top-level JSPs have been folded into
> the template JSPs. The net result is a set of JSPs that are slimmer,
> simpler and better organized. A few stray bugs (notably: JavaScript
> and a few URLBinding issues) remain, but the hard work is done.
>
> It is time to turn our sights towards getting an Alpha build out the
> door. Here are the current blockers as listed in JIRA:
>
> 1. JSPWIKI-303 JSPWiki-API library creation.
> 2. JSPWIKI-421 JCR backend
> 3. JSPWIKI-382 Remove posteditor.js
>
> We should make some decisions soon about whether these are really
> blockers or not, and figure out what we need to do to close them if
> they are.
>
> I'd also propose solving three more issues before we can declare Alpha:
>
> 4. Clean unit tests. We still have about 30 renaming, ReferenceManager
> and related plugin tests that are failing. I *think* they might be
> related to a recent Priha vintage. The build should run clean before
> we release an Alpha.
>
> 5. URLConstructors. With the physical top-level JSPs gone, we now rely
> on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
> event. We should do the same for outgoing URL **generation** by making
> StripesURLConstructor the default. While we're at it, we should kill
> the other URLConstructors, because FileBasedActionResolver will allow
> URLBindings to be externally defined. For backwards compatibility,
> ShortUrlRedirectFilter allows legacy short URLs to be safely
> intercepted and redirected.
>
> 6. Refactor WikiBackgroundThread abstract class as JMX timer MBeans.
> This would eliminate our somewhat unreliable timer implementation.
> Today, background threads don't kill themselves reliably. I take full
> responsibility for this, but I also can't fix it easily, and would
> rather do it through JMX.
>
> I can do 5 and 6 fairly quickly if we agree to do them.
>
> Are these good priorities for Alpha? What else are we missing?
>
> Andrew
>