jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: Seeking Alpha
Date Mon, 15 Feb 2010 16:27:29 GMT

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

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.)


On Sun, Feb 14, 2010 at 7:03 PM, Andrew Jaquith
<andrew.r.jaquith@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 <dirk.frederickx@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
>> <andrew.r.jaquith@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 <dirk.frederickx@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
>>>> <andrew.r.jaquith@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 <harry.metske@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
>>>>>> 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 <andrew.r.jaquith@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
>>>>>>> energy
>>>>>>> around re-working the JSPs. As of last night's checkins, I feel
>>>>>>> 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
>>>>>>> "modernized" with JSTL, and the top-level JSPs have been folded
>>>>>>> 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
>>>>>>> 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
>>>>>>> related to a recent Priha vintage. The build should run clean
>>>>>>> we release an Alpha.
>>>>>>> 5. URLConstructors. With the physical top-level JSPs gone, we
>>>>>>> rely
>>>>>>> on Stripes URLBindings to map incoming *.jsp resquests to ActionBean
>>>>>>> event. We should do the same for outgoing URL **generation**
>>>>>>> making
>>>>>>> StripesURLConstructor the default. While we're at it, we should
>>>>>>> the other URLConstructors, because FileBasedActionResolver will
>>>>>>> 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
>>>>>>> This would eliminate our somewhat unreliable timer implementation.
>>>>>>> Today, background threads don't kill themselves reliably. I take
>>>>>>> responsibility for this, but I also can't fix it easily, and
>>>>>>> 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

View raw message