concept for future magnolia (possibly 3.5) (MAGNOLIA-587)

[MAGNOLIA-588] Refactoring vs JSF with Facelets vs Wicket Created: 31/Oct/05  Updated: 03/Dec/13  Resolved: 03/Dec/13

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Philipp Bärfuss Assignee: Unassigned
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Date of First Response:

 Description   

Here we discuss the way we refactor the dialogs



 Comments   
Comment by Philipp Bracher [ 02/Nov/05 ]

This is a very hard decission to take. Perhaps someone like to answer some of those questions:

  • Can one create dynamic dialogs (component hierarchy) in Wicket? I mean not based on templates but based on the configuration in the config repository
  • Can one save the data with Wicket in a dynamic way? There is no bean class for each paragraph defined in the config. Is there a way to solve that in Wicket? Perhaps using DynaBeans.
  • Has anyone used Facelets and thinks we should go for that?
  • Is someone offering some work or other support if we chose the one or the other solution?

Refactoring would be a lesser effort for the core team where JSF would bring a standardized framework

Comment by Janne Hietamäki [ 02/Nov/05 ]

> - Can one create dynamic dialogs (component hierarchy) in Wicket? I mean not based on templates but based on the configuration in the config repository

Yes, this can be done with Panels.

http://wicket.sourceforge.net/apidocs/wicket/markup/html/panel/Panel.html

> - Can one save the data with Wicket in a dynamic way? There is no bean class for each paragraph defined in the config. Is there a way to solve that in Wicket? Perhaps using DynaBeans.

Yes, no problem. This can be done with PropertyModels or custom Models.

http://www.wicket-wiki.org.uk/wiki/index.php/Newuserguide#Property_models

> - Is someone offering some work or other support if we chose the one or the other solution?

I have experience on both, Wicket and Magnolia internals and I could offer some help.

Comment by Philipp Bracher [ 03/Nov/05 ]

First of all: thanks for offering help. To make magnolia 3.0 real we will need experienced developers taking there parts.

Reading your comment I think we should take the option to use Wicket more serious since it is better following the principle of simplicity than JSF does. I will read myself a little bit deeper into the docs.

Are there any ideas how spread this technology currently is and will be in the future.

Philipp Bracher

Comment by Janne Hietamäki [ 03/Nov/05 ]

> Are there any ideas how spread this technology currently is and will be in the future.

Wicket is still quite new project, but is developing and maturing fast. More and more developers are using it, and most important, like it.

Weakest part of Wicket is still the documentation, but .API is clean and community support is great, so there should not be problems with that.

Janne Hietamäki

Comment by Philipp Bracher [ 09/Dec/05 ]

I would go for Wicket. This follows the concept of simplicity and gives us the best benefit. I do not have a proper reason, but a good feeling. With some help of the comunity we could do it soon.

Comment by Thomas Ferris Nicolaisen [ 09/Dec/05 ]

To attract the largest number of developers and users, I think we should either use the de facto web framework (which does not exist above JSP at current time), or make the web layer pluggable.

Is it possible to use different web frameworks at the same time based on file extension and configuration? Template folder would look like this:
/templates/jsp
/templates/servlets
/templates/wicket
/templates/jsf
/templates/portlets
/templates/...

Etc.. Sounds very complicated without having thought too much about it, but would definitely be grand if users could choose themselves. Choice of web frameworks is so disputed (and things will change a lot more in the next years, I guess).

Comment by Boris Kraft [ 09/Dec/05 ]

The templating will stay as JSP - wicket was proposed only for the rendering of the admin GUI (dialogs)

Your idea of allowing different kits for rendering is cool on one hand, on the other it will fragment the community (just imagine everybody is giving his examples in a different language!). For simple html templating I'd rather have smarter tags so that the JSP in general is HTML plus tags - easy enough so that any html dev can make sense of it. (but that should go to another thread).

Comment by Philipp Bracher [ 12/Jan/06 ]

Ugh ... finally I came to a conclusion: we use JSF!

Ok, I have to explain this a little. First I must mention after looking at Wicket I look at wicket as a realy nice framework. But JSF is better known and a lot of resources (components, developers, documentation, ...) are available. It is also better useable in JSP contexts what is important since the templating is still pure JSP. Therefore I think that magnolia will benefit more from a JSF implementation.

I walked deep in the JSF forest (a little afraid) finding a clearing called Facelets. Never else it was not what I was looking for (after knowing wicket), but I realized how easy JSF could be by dumping the JSP part.

Inspired by Facelets I made a custom ViewHandler and added templated components (using freemarker) and I ended up with what I liked:

  • the view tree is builded programmatically (like wicket -> the controls are instantiate and configured in the code and afterward passed to the templates)
  • the controls are templated (make the source readable and ready for changes)
  • everything provided from JSF (controls, validation, statemanagement, ..) is still working
  • since the root node is a page object the controls can provide javascripts and css to it

I will pack this into a independent magnolia-jsf module on which the new interface can rely on.

Comment by Philipp Bärfuss [ 03/Dec/13 ]

We use Vaadin since M5.

Generated at Mon Feb 12 03:18:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.