OK, I haven't looked at Stripes much but from what you're saying it's still a JSP front-end, so at least that portion of Ichiro's concerns would be alleviated if we went to Stripes, even if the controller code would be rewritten to Java. I like what you're saying about moving more of the code from scriptlets to JUnit-testable Java classes. If we switch to a framework I think we primarily would need a trailblazer to convert the code over (preferably the person who is most comfortable with the framework we're switching to); once done, it's normally pretty easy for others to extrapolate what needs to be done to update it.

I can't see any immediate benefit of Struts over Stripes, but one thing to consider about Spring MVC though, even if it is more complex/clumsy to set up, is that once you put Spring into your application it might be easier to incorporate more of Spring's bells and whistles--maybe with security, maybe other things JSPWiki may wish to quickly grab as it goes along. Then again, it is a heavier framework that might end up slowing JSPWiki down.

Glen

On 12/11/2012 07:07 PM, Juan Pablo Santos Rodríguez wrote:
Hi,

I think that the core idea of using Stripes is it's simplicity and
easiness. Having worked with it the last 3 years with it, I've found it
*way* easier than Spring MVC/Struts. I don't think of it as a replacement
for all JSP-related stuff, but as a replacement of all the controller JSPs
(./src/webdocs/*.jsp, which are 99% sriptlet). The big advantages here
would be replacing JSP debugging with JUnit tests, having a more simple
layer. Yes, that's doable with any modern framework, but with Stripes is so
easy; I believe that it would greatly simplify the current model.

However, looking at our current pace, carrying on with this migration would
mean a lot of effort (time). Right now, I'd rather focus on other more
community-growth oriented things, i.e., modularize current src, so it's
easier to hop in. Seems that now it's not the time of switching to Stripes,
and I don't know if we'll end switching (time + should be decided @dev),
although I'd really like to. I think at least it's something
worth-considering (a branch with a proof of concept on a 2.10 scope?).

As for the LDAP + AD authentication, @Andrew any insights will be highly
appreciated :-)


regards,
juan pablo

On Tue, Dec 11, 2012 at 11:28 PM, Glen Mazza<[email protected]>  wrote:

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 atwww.jspwiki.org, there are
some
pages on 3.0, too.

Regards
   Florian


----- Ursprüngliche Mail -----
Von: "Ichiro Furusato"<[email protected]>
An:[email protected].**org<[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].**org<[email protected]>
To:[email protected].**org<[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