Everybody is striving for siplicity!

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Everybody is striving for siplicity!

Ahmed Mohombe
Hi,

it seems to be the trend nowadays :).
Even Struts - can you belive it :) :
http://wiki.apache.org/struts/StrutsTi

Ahmed.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development
Reply | Threaded
Open this post in threaded view
|

Re: Everybody is striving for siplicity!

Malcolm Edgar-2
Yes people a realizing that the size of frameworks is a problem. On TSS people
are even backing away from "MVC/Action" frameworks.

I think the problem with Struts Ti, is that the foundations are all wrong.
Struts is trying to reuse very small objects, which aren't particularly
interesting (Forms, Actions etc), and to reuses these you need to write volumes
of XML.

The current application I am working on uses Struts (moderate size), and has a
1650 line struts-config.xml file and a 655 line tiles-def.xml file.

With Click the equivalent config file would be a about 30 lines (thanks Ahmed
for the autoload idea). Now just have to finish the remaining features, which
seems to keep growing..

regards Malcolm Edgar




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development
Reply | Threaded
Open this post in threaded view
|

Re: Everybody is striving for siplicity!

Ahmed Mohombe
> Yes people a realizing that the size of frameworks is a problem. On TSS people
> are even backing away from "MVC/Action" frameworks.
What I don't understand is why did it take so much? I mean, wasn't it obvious from
the beginning(~2000), or was the marketing for those frameworks so good that the people/developers
accepted everything?

> I think the problem with Struts Ti, is that the foundations are all wrong.
> Struts is trying to reuse very small objects, which aren't particularly
> interesting (Forms, Actions etc), and to reuses these you need to write volumes
> of XML.
You are right. I suppose that at the beginning of a project, people don't see this, cause
the examples and the proof of concept tests look very simple and easy to understand.
When the programmers get into real use cases, it's too late :).
Because the Ruby on Rail (XP) strategy:
1: code a little
2: show to customer
3: goto 1
doesn't work in most real projects, the developers don't get to fast in the real problems
of a framework - to be able to make very fast a switch.
In fact, I saw in my whole life only 2 projects where this type of interaction worked,
so even if the XP concept is very nice, it doesn't really works.

> The current application I am working on uses Struts (moderate size), and has a
> 1650 line struts-config.xml file and a 655 line tiles-def.xml file.
I'm in the same boat with my project :). Just that after many presentations and
shining demos, I was able to convince the team to drop tiles, and use SiteMesh :).
First they felt sorry to 'drop' all that hard obtained skill to use tiles the right
way - when they saw that they can use SiteMesh after a 30 minutes course at the same
skill level with many other advantages :D.

> With Click the equivalent config file would be a about 30 lines
This is great advantage for Click. And till other frameworks will catch up with such
a simplification, I'm convince we will find other areas to make things even more simple :).

>(thanks Ahmed
> for the autoload idea).
You are welcome.
To be sincere, it wasn't 100% mine :) : I saw how simple was SiteMesh compared
to Tiles, than I saw that all my Struts config files respect that kind of 'automap' convention
just not to make some typing errors in that thousand lines file :) - I was using copy&paste :).
Unfortunately to implement that with Struts would mean to drop any tool support,
and those WSAD diagrams and navigation is pretty good to give it up just like that.

> Now just have to finish the remaining features, which
> seems to keep growing..
Well, they are not that many :). Many of my issues are simply administrative(hence the request
for an 'administrative' category in JIRA :) ), and could  be done by other users with admin rights :).

Thanks in advance,

Ahmed.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development
Reply | Threaded
Open this post in threaded view
|

Re: Re: Everybody is striving for siplicity!

pbarnes
On 9/8/05, Ahmed Mohombe <[hidden email]> wrote:
> > Yes people a realizing that the size of frameworks is a problem. On TSS people
> > are even backing away from "MVC/Action" frameworks.
> What I don't understand is why did it take so much? I mean, wasn't it obvious from
> the beginning(~2000), or was the marketing for those frameworks so good that the people/developers
> accepted everything?

Unfortunately, it was not obvious.  Prior to 2000 was the time of the
"Internet boom" when speed to market meant everything.  It was also a
time when JSPs and Servlets were the "Sun standard".  As such Struts
was "revolutionary" as far as Java web development went.  Struts
wasn't sponsored by any corporation that I'm aware of, so marketing
wasn't a factor (unless you consider 'word of mouth').

> > I think the problem with Struts Ti, is that the foundations are all wrong.
> > Struts is trying to reuse very small objects, which aren't particularly
> > interesting (Forms, Actions etc), and to reuses these you need to write volumes
> > of XML.
> You are right. I suppose that at the beginning of a project, people don't see this, cause
> the examples and the proof of concept tests look very simple and easy to understand.
> When the programmers get into real use cases, it's too late :).

I agree.

> Because the Ruby on Rail (XP) strategy:
> 1: code a little
> 2: show to customer
> 3: goto 1
> doesn't work in most real projects, the developers don't get to fast in the real problems
> of a framework - to be able to make very fast a switch.

This I disagree with.  First, as far as I know, there is no 'Ruby on
Rails strategy' and certainly XP != RoR.  I'll assume you mean an
'iterative' approach though, which does work, but requires management
buy-in, which is extremely rare -- mostly due to short sitedness.  In
my personal, professional and humble opinion, this same management is
often the same cause of over-budget, over-deadline projects.  Usually
technology is not the culprit, but rather poor management that leads
to failures.

> In fact, I saw in my whole life only 2 projects where this type of interaction worked,
> so even if the XP concept is very nice, it doesn't really works.

My experience is that an iterative approach would have worked in far
more places than the "typical" (waterfall) approach, and
unfortunately, I've been on a lot of over-budget, over-deadline
projects over many years at many large, large corporations.

> > The current application I am working on uses Struts (moderate size), and has a
> > 1650 line struts-config.xml file and a 655 line tiles-def.xml file.
> I'm in the same boat with my project :). Just that after many presentations and
> shining demos, I was able to convince the team to drop tiles, and use SiteMesh :).
> First they felt sorry to 'drop' all that hard obtained skill to use tiles the right
> way - when they saw that they can use SiteMesh after a 30 minutes course at the same
> skill level with many other advantages :D.

Yeah, I have to agree here again.  Struts and Tiles configs can get
really crazy.  My last Struts project had 7 struts-configs (as well as
7 tiles-defs) each with several hundred lines -- not fun, but it
worked.  We tried to move to SiteMesh, for it's comparative
simplicity, but when coupled with Spring's OpenSessionInViewFilter and
trying to load data for a "decorator" became problematic.  Still, I'd
revisit it in the future.

> > With Click the equivalent config file would be a about 30 lines
> This is great advantage for Click. And till other frameworks will catch up with such
> a simplification, I'm convince we will find other areas to make things even more simple :).
>
> >(thanks Ahmed
> > for the autoload idea).
> You are welcome.
> To be sincere, it wasn't 100% mine :) : I saw how simple was SiteMesh compared
> to Tiles, than I saw that all my Struts config files respect that kind of 'automap' convention
> just not to make some typing errors in that thousand lines file :) - I was using copy&paste :).

Either way, thanks for the idea -- I'm fond of it as well :)

> > Now just have to finish the remaining features, which
> > seems to keep growing..
> Well, they are not that many :). Many of my issues are simply administrative(hence the request
> for an 'administrative' category in JIRA :) ), and could  be done by other users with admin rights :).

As much as I'd love to have the administrative work taken out of my
hands (what a bore ;), since the servers are my responsibility, I'm
afraid this won't happen.  :(

Phil..


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development