Hi!

My 2 cents on the JSP issue:
1) I choose to work with JSPWiki because it was JSP based !
2) I evaluated different framework and always stayed with basic JSP...
Why? It is simple: users wants solutions right away, you have no time to refactor a whole software, you must be reactive. Too often Java architects are proposing complex solutions when we do not have something simple like PHP to rapidly serve users. I just gave a Web Application Development course with JSPs. Students were reluctant because they much prefer PHP. At the end, they were surprised how simple and straight to the point JSPs can be. 3) I just gave a try to SUGAR, the Linux adaptation for OLPC (One Laptop per Child) It shows how SIMPLICITY could be the way for most of our professional users... JSPWiki should be able to work their School Server but this is another story...

I would propose:
a) WYSIMYG is a must for usage SIMPLICITY. Precise, simple and FAIL SAFE implementation. b) Some semantic feature is needed (wiki pages seen as a Dictionary/vocabulary entry), links seen as a relation with some URL with the possibility to enrich display using the data around linked URLs
    "JSPWiki, a partner application in the Semantic / Linked Open Data Web"
c) No dramatic changes needed: we must never forget the installed base.
    Simplifications allowed though...
d) Improve technical documentation to provide clear instruction how to extend at different levels.

On my side (within my limited time), I will try to provide proposals for a) and b).
a) : Ichiro already provided me with a XSLT basis for XHTML->Wiki markup:
   I still have to install it.
b) : I have already a support for:
* A Wiki page documenting a topic used to index different databases is enriched with usage statistics (and links) in those databases. Example: http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=jita_THIN&profile=guest * InterWikiLinks can be made toward a topic (and from there to the databases using that topic): they remain to be enriched by a preview popup presenting the statistics and the links directly (As an example, I added an InterWikiLink to jita:SONL a.k. "On Line Server" in the above page)

Refactoring OK but only if it brings BOTH :
1) functions requested by users (they "pay" for our work, is'nt it?)
2) cleaner, simpler, software easier to manage, to install and to integrate

Have a nice day!

Christophe


Le 11/12/2012 23:28, Glen Mazza a écrit :
I'm inclined to agree with Ichiro here. Perhaps it is too late in the game for me to comment, but if--if!--JSPWiki is going to use a framework I would recommend a very commonly used one like Struts 2 or Spring MVC, even if there are smaller competitors that may, in fact, be better. Part of the allure of projects like JSPWiki is that it's web development that helps strengthen skills that are easily translatable to the job. So in attracting committers I think it would be good for the project to remain with the most common in-demand tools that people are most likely to see out in the marketplace.

Glen

On 12/11/2012 03:40 PM, Ichiro Furusato wrote:
Hi Andrew,

I know it's terribly unfashionable to say this, and I understand
there has been a significant amount of work on 3.0 towards Stripes
(and perhaps this is also somewhat of an academic argument), but
I really much prefer the JSPs. No, there's no framework, no "real"
MVC, and this likely goes against the current of thought, but
frankly I consider the use of scriptlets a real benefit, not a
problem.

JSPWiki is not so complicated an application, and wikis are by
nature a tinkerer's toy, that shoving everything up into a framework,
adding in complicated features that make modifying the site more
difficult, well, the move away from JSPs was one reason I was
considering moving away from the JSPWiki platform.

It is after all named *JSP*Wiki.  I happen to think that the
combination of JSPs, with their easy-to-edit combination of HTML
and Java code, as an ideal environment for customising wikis.
Maybe we could rebrand this project as "retro" and it would gain
enormous momentum.

My 2 cents anyway...

Ichiro

On Wed, Dec 12, 2012 at 8:22 AM, Andrew Jaquith
<[email protected]> wrote:
From the vantage point of someone who is inactive with the project, but
also the principal author of the Stripes MVC integration:

- Stripes had several goals, chiefly to (1) refactor the JSP scriptlet code
out of the JSPs and into proper JavaBeans ("ActionBeans" in Stripes
parlance)
- Simplify JSP markup and input validation (replace HTML form tags with
Stripes equivalents)
- Replace the "command pattern" extensions to WikiContext, introduced in
the 2.8 range, with something saner (the ActionBeans)
- Create a more solid back-end interface for managing JSON requests from
browsers

Almost all of the forms porting was done, plus or minus a few things. I was
pretty happy with how it turned out. There is some wickedly clever JSON
processing in there (via the Interceptor classes) that was barely tapped; it would have radically simplified a lot of Dirk's code. Yes, Stripes is another framework, but it's pretty lightweight; and much, much lighter than Spring, for example. On the flip side, it's not in widespread use; indeed, Spring has pretty much steamrollered over most of the other JEE frameworks,
even as lots of dev energy has left the Java world entirely.

One more thing about 3.0. I added in some pretty solid code for integrating with LDAP and AD for authentication, group access controls, etc. This could
be re-used in the 2.9 codebase pretty easily, with a little light
refactoring.

Whether the team wishes to use the rest of 3.0 code (including Stripes) is,
of course, up to the team. If I can be a resource/mentor, let me know.

Andrew

On Mon, Dec 10, 2012 at 1:45 AM, Florian Holeczek <[email protected]>wrote:

Hi Ichiro,

well, that's basically it - more than enough I'd say, since these two are really big points. You can have a look at www.jspwiki.org, there are some
pages on 3.0, too.

Regards
  Florian


----- Ursprüngliche Mail -----
Von: "Ichiro Furusato" <[email protected]>
An: [email protected]
Gesendet: Sonntag, 9. Dezember 2012 23:53:08
Betreff: Re: [DISCUSS] How to proceed with the 3.0 efforts

For those of us who've not followed the 3.0 progress (or lack thereof),
could
someone provide a very brief synopsis?

My understanding is that the 2.8.x branch is fully functional and
basically an
update of the com.ecyrd.jspwiki code in Apache packaging, and that the 3.0 branch was an attempt to rewrite the backend using Janne's JSR-170 subset, but that hasn't moved forward. I didn't know about any plans for Stripes.
But
this is all just a guess based on:

A new effort is started to graduate with a 2.9 codebase (based on 2.8), so no JCR backend and no Stripes, but the traditional JSPWiki, the
     progress can still be followed at our JIRA issue tracker.

[I'm frankly happy with the "traditional" 2.8/2.9 code base as it's
compatible with a substantial number of extant projects and plugins.
I'd prefer JSPs over Stripes, or anything that adds complication.]

If there's a web page describing the goals of 3.0, a reference would
be good. The JIRA roadmap isn't that helpful.

Thanks,

Ichiro

On Mon, Dec 10, 2012 at 12:31 AM, Florian Holeczek <[email protected]>
wrote:
Hi all,

sooner or later we will have to decide on how to proceed with the 3.0
efforts (available in the JSPWIKI_3_0_BRANCH).
The discussion already started on a different thread (see below), but I
think it's a good idea to explicitly continue it on a new thread.

@Harry: I fully agree with your mail cited below.
Though I wish it was different, I personally have little hope on reviving 3.0 without the help of Janne and Andrew, which seems unlikely at least
in
the medium term.

What do the others think, especially Janne and Andrew?

Regards
  Florian


-------- original message --------
Subject: Re: [jira] [Commented] (JSPWIKI-713) Creating a page doesn't
work
on 3.0
Date: Sun, 9 Dec 2012 12:12:59 +0100
From: Harry Metske <[email protected]>
Reply to: [email protected]
To: [email protected]

Agree with that statement. But let's then decide what to do with 3.0
stuff.
My main objection is that it is cluttering up our JIRA issue list, and it
is misleading people.

If anyone of us still has some hope on reviving 3.0 then I'm OK with
leaving things as they are at the moment.

regards,
Harry




Reply via email to