Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dirk.frederickx@gmail.com
 designates 72.14.220.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=vbXIT5L8/isBC1X1CknFTmYRlBPhJ3RPsKMnbC/FsHMwvgcYaRbICjnz4NmUWlpfI7
         qeWw/1zqPti6yiiUp2ux5iZSFXFJ93DK3We4ipoQcvRN8daoNcAJcrcy5RaGRzbHnEDO
         027fQvzOI87vnfAnwIfjbO5557DdnEGR4s51g=
MIME-Version: 1.0
In-Reply-To: <b90102161002271137k6f3cb1dci8c74aeeae387bf8@mail.gmail.com>
References: <15cc92001001231039t3fbcbafei4cd08b8e23f8643e@mail.gmail.com>
	 <3a6c97f01002210250h676d00f6h7c52f2811eea706a@mail.gmail.com>
	 <15cc92001002221219m213c7324p770b0748c3c657df@mail.gmail.com>
	 <b90102161002231435v55bd642ev2fa7f426f040fbce@mail.gmail.com>
	 <15cc92001002270416o6c9ce382s32b2c5eadf39b618@mail.gmail.com>
	 <15cc92001002270423x1f6410bm6c3917a13b235438@mail.gmail.com>
	 <1D276A22-88BF-45CE-A357-1D69605362F8@gmail.com>
	 <15cc92001002270551g237c76ddmf5fe2d6ee88a0744@mail.gmail.com>
	 <3a6c97f01002271004o31d9e6en6afd3355c7fb931e@mail.gmail.com>
	 <b90102161002271137k6f3cb1dci8c74aeeae387bf8@mail.gmail.com>
Date: Sun, 28 Feb 2010 10:33:59 +0100
Message-ID: <15cc92001002280133r15fdc378q14a54fa149a6dd0f@mail.gmail.com>
Subject: Re: help with v3.0.0-svn-200
From: Dirk Frederickx <dirk.frederickx@gmail.com>
To: jspwiki-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001485f6455c14c6530480a5d579

--001485f6455c14c6530480a5d579
Content-Type: text/plain; charset=ISO-8859-1

SPAM

> now, at least) are very sensitive. A double-submit of a form, for
> example could trigger the spam detectors because of the "one-time"
> token we embed as a hidden form parameter.
>
> So, let me know what you do to make it happen, and I'll look into it.

>>>could indeed be that I had some double submits
>>>in the javascript, the prevention double-submits has been removed  (eg.
disabling a submit button once it is clicked the first time )    why is
that?


Whenever this happens, it is a bug. If it's in the JSP markup, that
> markup should use the JSTL syntax "${templates['Error.jsp']}" rather
> than "/Error.jsp". It's easy to fix, and if you encounter it I'd just
> ask that you commit a fix. I'll look for these myself, although I
> thought I'd eliminated them. This was a VERY recent change, so it is
> likely there are a few instance of this kicking around.

>>>one is missing from the AttachmentTab.jsp,  but I'm not sure whether this
jsp is still used.
>>>anyway, I run into the problem when using Install.jsp  (no reference here
to an errorPage) and Login.jsp (idem) Is this correct ?


> The UI at the top of the page was very cluttered: it had the save
> button, change-note, and toolbar. It seemed simpler and cleaner to
> have it at the bottom.

>>> I suggest to take it back at the top.  The 'clutter' should be minimal:
only one extra line with SAVE/CANCEL button and the change-note.
>>> Alternatively, we could embed the buttons in the toolbar as well.


FYI: one thing that you may note as you peruse the new template JSPs
> is that I've deliberately broken up the tabs so that the "view"
> feature (eg., Wiki.jsp) only loads the View tab; the other tabs link
> to other JSPs e.g., PageInfo.jsp. That is deliberate -- I wanted to
> make generating view pages fairly lightweight. But if a user clicks on
> "Info" or "Attachments," then we load the other tabs and make them
> clickable via JavaScript. The user won't notice the difference.

>>>Ok for the info tab.
>>>However, I would prefer to avoid a server-roundtrip for the attachment
tab.
>>>It would be faster to toggle to the attachment tab to preview some of the
attachments.
>>>Especially during editing, when previewing attachments you don't want to
be taken out of the edit session.

>>>Alternatively, we could load the attachment tab through an AJAX call,
without refreshing the page.
>>>This keeps the initial page-size limited.


This is something I have not done yet. I didn't think it was needed
> for the beta. I don't understand what the "raw" editor really does,
> and I'm not really sure it is an "editor." What's the rationale for
> this feature? If it is needed, then of course we need to get it
> working. Whether we need it for Alpha, I don't know.

>>>Agree. Terminology may be confusing here.
>>>"SKIN=RAW" is not an editor actually -- it just a way to view the raw
markup of the page.  (a link is avaible in the More dropdown)
>>>Actually, the generation of the raw page content could be a served from a
simple basic JSP as well, as part of the default template.


> If this occurs, it is a bug. Any code that generates links to
> "standard" images should use TemplateManager.getResourceResolver() to
> obtain the path to the image. I thought I caught all of these, but if
> I didn't, please commit a fix.
>
> >>>The issue here is in the markup-to-html converter which generates
hardcoded the <a...> links.
>>>Actually the generated link is ok.
>>>However the generated <img ...> needs to be fixed.
>>>As a fix, I suggest to remove the generated <img ..> completely;  and
resolve the presentation of external links completely in the jspwiki.css.
 (so it becomes skin-able as well)
>>>I will commit a fix for this.


dirk

--001485f6455c14c6530480a5d579--