Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-28 Thread Erik van Oosten
I just did a little blog about the results of the thread: http://day-to-day-stuff.blogspot.com/2006/09/wicket-for-bscs.html Thanks, Erik. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's

[Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Erik van Oosten
Okay, so we've got: Irrefutable arguments for using wicket in big slow companies: * Very small learning curve. Comment: Agreed. But I still think you need at least one more experienced Wicket developers for more advanced things like manipulating html generated by other

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Erik van Oosten
I like those. Lets hold them against the unfair criteria again (this is really fun): - Developer team scalability: Nice, this is indeed something large companies need and/or struggle with. Who has never had revision 1285 of struts-config.xml? And many big companies like splitting up work over

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Eelco Hillenius
- Reusability: I have unfortunately never seen a big slow company that cared about this. Please tell me if you saw some. - Maintainability: I have not seen many big slow companies that cared about this deeply. Furthermore, the big companies I worked at 'maintainability' is usually associated

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Erik van Oosten
Eelco, IMHO, what you describe here is 'flexible development' (I am avoiding the term Agile) rather then reusability and maintainability. Can you agree with this (somewhat condensed) assessment? Erik. Eelco Hillenius schreef: For both arguments: they *should care* about that and it

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Erik van Oosten
I understand and I agree wholeheartedly. I appreciate and like your complete and thorough answers. But for BSCs (thanks for the TLA Che) we'll need terse and to the point arguments. I'll wait another day for some more comments and then write a little article about this discussion. Should be

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Eelco Hillenius
IMHO, what you describe here is 'flexible development' (I am avoiding the term Agile) rather then reusability and maintainability. Can you agree with this (somewhat condensed) assessment? Sure, whatever works for you :) What I tried to get across is that I don't think reusability and

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Eelco Hillenius
* Very small learning curve. Comment: Agreed. But I still think you need at least one more experienced Wicket developers for more advanced things like manipulating html generated by other components. Of course, books like 'Pro Wicket' help a lot but are not for

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Eelco Hillenius
I'm missing my favorites :) - Scales very well for development. Whether you're working in a team of 2 people or 20, you'll have all the possibilities of breaking functionality down in smaller pieces. Let your developers works on whole pages, or just (reusable) panels, or even on highly

Re: [Wicket-user] Wicket arguments for big slow companies (Was: links about wicket scalability...)

2006-09-26 Thread Erik van Oosten
Hi Eelco, Nino, I'm not even sure whether I agree :) Wicket can be hard for people that are not comfortable with OO programming... I did not have a very small learning curve, nor did the two other consultants working here. I guess 'very small learning curve' is off then. I must