Something to think about maybe

[Christian Grobmeier <gr...@gmail.com>]

Comparison of web frameworks:

http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

Lot of the things this guy said on Struts isn't accurate.
A few things are worth to think about it:

Quote:

"Many devs see Struts as a legacy technology, so don’t expect fancy code
generation in the place of boilerplate code. You need to configure a lot
to start prototyping. An example project can be a good starting point.
Something on the bright side: Struts has a Convention plugin, that
enforces some convention over configuration and provides annotations to
configure URL mappings and some other stuff. This should speed up things
a bit.

Score: 2/5 – Lots of boilerplate code, no built-in code generation, no
external powerful tools."

This guy certainly did miss maven archetypes. Asides from that, we
actually could think about some code generation tools. For example:

$> struts-gen.sh de.grobmeier.app.LoginAction

Generated LoginAction.java
Generated login.jsp

This paragraph also tells me we should stick with the idea of pushing
the Convention plugin.

Later the author wrote:

"Awful official documentation. User-written tutorials are slightly better."

As already discussed today, I think this is not so wrong.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Something to think about maybe

[Christian Grobmeier <gr...@gmail.com>]

Am 09.09.13 11:32, schrieb Lukasz Lenart:
> 2013/9/4 Steven Benitez <st...@gmail.com>:
>> I know it's the plan to move to Git, but that can't happen soon enough.
>> Subversion is like a big cloud of sadness.
>>
>> On the bright side, it would be great to get a concerted effort at creating
>> new documentation. I'd be happy to help.
> One thing to think of when migrating to a new mechanism (i.e. Markdown
> and Jekyll) - security. Right now in Confluence I'm able limit access
> to some pages by specifying access rights - it's very useful mechanism
> when we're preparing a Security Bulletin and Release Notes which
> shouldn't be publicly available before patch is ready and we are
> releasing new version.
Good point. Maybe we should work on security bulletins in the wiki
first, and only after a given time move them to the standard page.


>
>
> Regards


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Something to think about maybe

[Rene Gielen <re...@gmail.com>]

As you might know, we had a hackathon this weekend in Augsburg, Germany
(http://strutsathon.opensource.io/) where we experimented a bit with
available options and requierements.

One of the outcomes was that we may want to start with a "real" user
guide that helps to get started and addresses common learning topics.
Meanwhile the Confluence docs could stay in place, still containing
detailed reference information (which the user guide may link to) and
technical information such as security bulletins etc.

Thus we could address the general issue of ramping up users to be
productive with Struts 2 without the need to throw away confluence for
now. Once we have both a reliable lifecycle management for SCM authored
content and the intended content itself in place, we can rethink our
next steps with / without confluence.

For the technical side, two smart guys who joined us at the hackathon
started to address this together with Christian and me with research on
how Markdown based authored content could be built in our maven
environment and how Snippets could be integrated seamlessly here as well.

Some work is already open for review now / in near future:
https://github.com/organizations/opensourceio

- René

Am 09.09.13 11:32, schrieb Lukasz Lenart:
> 2013/9/4 Steven Benitez <st...@gmail.com>:
>> I know it's the plan to move to Git, but that can't happen soon enough.
>> Subversion is like a big cloud of sadness.
>>
>> On the bright side, it would be great to get a concerted effort at creating
>> new documentation. I'd be happy to help.
> 
> One thing to think of when migrating to a new mechanism (i.e. Markdown
> and Jekyll) - security. Right now in Confluence I'm able limit access
> to some pages by specifying access rights - it's very useful mechanism
> when we're preparing a Security Bulletin and Release Notes which
> shouldn't be publicly available before patch is ready and we are
> releasing new version.
> 
> 
> Regards
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Something to think about maybe

[Lukasz Lenart <lu...@apache.org>]

2013/9/4 Steven Benitez <st...@gmail.com>:
> I know it's the plan to move to Git, but that can't happen soon enough.
> Subversion is like a big cloud of sadness.
>
> On the bright side, it would be great to get a concerted effort at creating
> new documentation. I'd be happy to help.

One thing to think of when migrating to a new mechanism (i.e. Markdown
and Jekyll) - security. Right now in Confluence I'm able limit access
to some pages by specifying access rights - it's very useful mechanism
when we're preparing a Security Bulletin and Release Notes which
shouldn't be publicly available before patch is ready and we are
releasing new version.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Something to think about maybe

[Steven Benitez <st...@gmail.com>]

I know it's the plan to move to Git, but that can't happen soon enough.
Subversion is like a big cloud of sadness.

On the bright side, it would be great to get a concerted effort at creating
new documentation. I'd be happy to help.


On Wed, Sep 4, 2013 at 1:35 PM, Paul Benedict <pb...@apache.org> wrote:

> Christian, I agree on the "awful" documentation part. The S1 documentation
> is better organized than S2. I thank everyone who wrote S2 documentation,
> but it is incredibly difficult to sift through to find an answer. The wiki
> may not be the right tool for the documentation although I don't have an
> alternative except HTML files in SVN (like S1). If we can do anything to
> make it more readable (even correcting the font and font size), I am all
> for it.
>
>
> On Wed, Sep 4, 2013 at 12:32 PM, Christian Grobmeier <grobmeier@gmail.com
> >wrote:
>
> > Comparison of web frameworks:
> >
> >
> >
> http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/
> >
> > Lot of the things this guy said on Struts isn't accurate.
> > A few things are worth to think about it:
> >
> > Quote:
> >
> > "Many devs see Struts as a legacy technology, so don’t expect fancy code
> > generation in the place of boilerplate code. You need to configure a lot
> > to start prototyping. An example project can be a good starting point.
> > Something on the bright side: Struts has a Convention plugin, that
> > enforces some convention over configuration and provides annotations to
> > configure URL mappings and some other stuff. This should speed up things
> > a bit.
> >
> > Score: 2/5 – Lots of boilerplate code, no built-in code generation, no
> > external powerful tools."
> >
> > This guy certainly did miss maven archetypes. Asides from that, we
> > actually could think about some code generation tools. For example:
> >
> > $> struts-gen.sh de.grobmeier.app.LoginAction
> >
> > Generated LoginAction.java
> > Generated login.jsp
> >
> > This paragraph also tells me we should stick with the idea of pushing
> > the Convention plugin.
> >
> > Later the author wrote:
> >
> > "Awful official documentation. User-written tutorials are slightly
> better."
> >
> > As already discussed today, I think this is not so wrong.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> Cheers,
> Paul
>

Re: Something to think about maybe

[Umesh Awasthi <um...@gmail.com>]

Even when i go for search about struts2 documents there are variety of
resources available and that can make more confusion.
Not sure about wiki, but honestly i like the documentation of Spring in
place, if i want i can have HTML pages or option of PDF is also available
there, more over there are not multiple versions of same set of
documentation.




On Wed, Sep 4, 2013 at 11:05 PM, Paul Benedict <pb...@apache.org> wrote:

> Christian, I agree on the "awful" documentation part. The S1 documentation
> is better organized than S2. I thank everyone who wrote S2 documentation,
> but it is incredibly difficult to sift through to find an answer. The wiki
> may not be the right tool for the documentation although I don't have an
> alternative except HTML files in SVN (like S1). If we can do anything to
> make it more readable (even correcting the font and font size), I am all
> for it.
>
>
> On Wed, Sep 4, 2013 at 12:32 PM, Christian Grobmeier <grobmeier@gmail.com
> >wrote:
>
> > Comparison of web frameworks:
> >
> >
> >
> http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/
> >
> > Lot of the things this guy said on Struts isn't accurate.
> > A few things are worth to think about it:
> >
> > Quote:
> >
> > "Many devs see Struts as a legacy technology, so don’t expect fancy code
> > generation in the place of boilerplate code. You need to configure a lot
> > to start prototyping. An example project can be a good starting point.
> > Something on the bright side: Struts has a Convention plugin, that
> > enforces some convention over configuration and provides annotations to
> > configure URL mappings and some other stuff. This should speed up things
> > a bit.
> >
> > Score: 2/5 – Lots of boilerplate code, no built-in code generation, no
> > external powerful tools."
> >
> > This guy certainly did miss maven archetypes. Asides from that, we
> > actually could think about some code generation tools. For example:
> >
> > $> struts-gen.sh de.grobmeier.app.LoginAction
> >
> > Generated LoginAction.java
> > Generated login.jsp
> >
> > This paragraph also tells me we should stick with the idea of pushing
> > the Convention plugin.
> >
> > Later the author wrote:
> >
> > "Awful official documentation. User-written tutorials are slightly
> better."
> >
> > As already discussed today, I think this is not so wrong.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> Cheers,
> Paul
>



-- 
With Regards
Umesh Awasthi
http://www.travellingrants.com/

Re: Something to think about maybe

[Paul Benedict <pb...@apache.org>]

Christian, I agree on the "awful" documentation part. The S1 documentation
is better organized than S2. I thank everyone who wrote S2 documentation,
but it is incredibly difficult to sift through to find an answer. The wiki
may not be the right tool for the documentation although I don't have an
alternative except HTML files in SVN (like S1). If we can do anything to
make it more readable (even correcting the font and font size), I am all
for it.


On Wed, Sep 4, 2013 at 12:32 PM, Christian Grobmeier <gr...@gmail.com>wrote:

> Comparison of web frameworks:
>
>
> http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/
>
> Lot of the things this guy said on Struts isn't accurate.
> A few things are worth to think about it:
>
> Quote:
>
> "Many devs see Struts as a legacy technology, so don’t expect fancy code
> generation in the place of boilerplate code. You need to configure a lot
> to start prototyping. An example project can be a good starting point.
> Something on the bright side: Struts has a Convention plugin, that
> enforces some convention over configuration and provides annotations to
> configure URL mappings and some other stuff. This should speed up things
> a bit.
>
> Score: 2/5 – Lots of boilerplate code, no built-in code generation, no
> external powerful tools."
>
> This guy certainly did miss maven archetypes. Asides from that, we
> actually could think about some code generation tools. For example:
>
> $> struts-gen.sh de.grobmeier.app.LoginAction
>
> Generated LoginAction.java
> Generated login.jsp
>
> This paragraph also tells me we should stick with the idea of pushing
> the Convention plugin.
>
> Later the author wrote:
>
> "Awful official documentation. User-written tutorials are slightly better."
>
> As already discussed today, I think this is not so wrong.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
Cheers,
Paul