On 8/29/06, Troy MacNeil <[EMAIL PROTECTED]> wrote:
> De-lurking twice in one day, rare indeed;) I'm very much in favour of
> the "toolkit with a capable sample application" approach though.
> When I've used PHP I've found that the concept of a plug-in for a PHP
> CMS is very informal and undefined. If you want to create a file upload
> plug-in you write a file upload page. You tie it into the rest of the
> CMS almost as an afterthought.
> This lack of rigour leads to some very ugly plug-ins code wise, but
> makes it very easy to write a plug-in or change existing functionality.
> I think that is why there is such a community and so many available
> (often overlapping) plug-ins.
> The Java response to this (JSR-107) has been to create large monolithic
> CMSs which use template engines to hide some of the complexity. In

> practise, it makes does make basic templating simple while extending
> functionality or adding new functionality actually becomes more
> daunting.
> I think this would ultimately be just as true of a large CMS using
> Wicket for presentation as any of the other presentation layers in use.
> I also think it misses the point. Simplify database access with
> Hibernate. Simplify the presentation by hiding complex code in
> components. Ditch templating in favour of some loosely coupled Wicket
> pages using Wickets own HTML separation. I think you'd end up with
> something that competes very well with PHP in terms of simplicity and
> ease of modification while retaining access to the benefits of Java.
> All this is just my opinion, and a simpler sample application like what
> I envision could easily grow into a larger CMS with time or co-exist
> with a more ambitious CMS project.
> Troy

Sounds good to me. My special remarks here would be:

1) Take extra care of scalability. Wicket provides you with tweaking
options (like stateless components now) if you need them. A CMS that
hosts Wicket components should leave such options open too, and the
CMS end-user part should run 'stateless' by default; other parts, that
require logging in, wouldn't need this restriction).

2) The basis should be rock solid. Before people would go wild
developing all kinds of plugins etc, you want something that works
really well (but is still as simple as possible). That's what we tried
with Wicket's versions so far, and I hope we did a decent job at that.

3) If plugins are an important part, OSGi (like
http://cwiki.apache.org/FELIX/index.html) would be very helpful. This
would make it possible to drop in plugins/ components on a running
site, and we wouldn't have to built yet another plugin mechanism.

4) I'm not the greatest standards buff on earth, but in this case,
using JSR 170 would make sense imo. Contrairy to some other JSRs, this
JSR has been backed by implementations from the beginning (though
personally I'd have loved if that would have moved faster), and it is
focussed on functionality especially for CMSses (with nice extra's
like WEBDAV access, different deployment models, etc).

5) While we're at it, we could consider portlet support. It helps to -
even though it wouldn't be implemented right away - plan for such
things so you don't make decisions that'll make it impossible in the

I think the trick would be to look at these issues in abstraction.
Planning for them, and designing the API to fit it wouldn't always
mean implementing it. We (or the people that take this task up) could
implement something really simple that works without OSGi and JSR 170.
But it would be great if such support could be built in later.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to