[MAGNOLIA-129] Refacor control objects Created: 22/Oct/04  Updated: 23/Jan/13  Resolved: 24/Nov/05

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

Type: Improvement Priority: Major
Reporter: Pascal Mangold Assignee: Philipp Bärfuss
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Comments   
Comment by Michael Aemisegger [ 06/Jan/05 ]

Magnolia Controls are quite good from a user perspective view. But from a developers perspective view the controls are clumsy, not customizable, not extensible and a pain in the ass.

Why reinvent the wheel? I'd appreciate to see magnolia use a component oriented framework (e.g. Tapestry, JSF, MyFaces, Echo) or at least a MVC framework (e.g. Struts) for the admin & authoring user interface. Magnolia's architecture would improve considerably in my opinion.

3rd party extensions to magnolia (like mine) could be integrated much easier.

I propose my help on this issue.

Comment by Michael Aemisegger [ 07/Jan/05 ]

Rereading my comment I realize that I probably should explain my thoughts somewhat more.

I customized some of magnolias JSPs (e.g. extractTree.jsp) and beans (e.g. Tree) to fit my needs. I had some hard time to understand what was going on behind the scenes. I appreciate that much of the mysterious JSP code found its way to java classes. Also, the extensive use of beans is helpful.

My difficulties lie in the understanding of what happens when in what order. It is also almost impossible to hook in some extra code upon an action (e.g. create new user) without patching magnolia. In an admirable effort you have created some kind of bean oriented framework. And here my criticism hooks in. Why do you try to reinvent the wheel? I know, why questions are dangerous. So let me emphasize the advantages of an alternative approach of a component oriented framework:

  • rich library of already existing components (e.g. ColorChooser, DateControl, TreeControl etc.) which can easily be extended
  • well proven component lifecycles and process flows
  • well known framework for a broad community of developers or at least well documented
  • nestable components
  • declarative control of process flows
  • code in terms of objects, methods and properties, not URLs and query parameters
  • components added to the framework in the future that can be used
  • built-in i18n

I understand that this architectural request requires a substantial amount of work and probably is not on top of your list. But looking back at my own software projects teaches me that you always gain from well designed pieces of code in the end. And if you want magnolia to become an evolving open source community project then developers should feel at home without too much pain.

Again, don't take me wrong. I like the GUI very much from a users point of view and right now it wouldn't be too much work to migrate to a well proven and reliable framework. It will get harder the longer you wait. Therefore I vote for a refactoring of the controls in a component oriented framework, preferably Tapestry (http://jakarta.apache.org/tapestry/) or Java Server Faces.

Cheers,
Michael

Comment by Boris Kraft [ 07/Jan/05 ]

Our original reasoning behind what we did was to be standards compliant. That means J2EE technologies, which at the time meant JSP.

Personally, I am the first one who will tell you that JSP is terrible, and I will not need to argue, others have done that (search on google why jsp is crap).

I am used to an environment that is lightyears ahead of JSP called webobjects. So I know what I would like to have. Personally I think velocity would be a great fit.

Now along comes JSF, and we just might have to reevaluate things. This is certainly on the agenda for M3, but that will be a while as you have noticed, others things are more important.

Some of the issues you have noted should be solved differently anyways. I have a couple things on my mind that will allow a great level of customization - one is a global event notification mechanism, where all relevant events get posted and your custom code can register to get notified for things it's interested in (the "create user" example) and two is the workflow engine, which will be embedded in such a way that anything is workflow. So if you create a user, it will actually be a workflow that is started, and you can customize the workflow to do additional stuff - send a password to the user, register with LDAP, write a log - whatever. The third area we need to work on is the module stuff. Here I imagine you should be able to register/hook stuff into what is there. I am currently working on a project where the user dialog has a second tab with custom functionality, and it would be nice to simply define that tab in your module and add it either via config or from your module code – something like: userDialog.addTab(customTab);

I think that with these additions, we will be very open for customizations independently of the templating mechanism or app framework used.

While your arguments are valid in itself, I think that we will have to consider very carefully what it would mean to have the same functionality, look & feel we have now but using a different framework. Will we gain enough to make that transition worthwhile?

We have all the controls you need plus an easy way to add custom controls. It is very easy to create your custom dialogs. It is very easy to create and use a custom control. You can extend every GUI element we have - add buttons to the main bar etc. – all using standard JSP.

I assume that if there is anything as cool as our tree element in another framework, it will have at least the same complexity and it will be just as hard to customize it.

Finally, just because a lot of people use something doesn't mean its any good. Look no further than struts (or JSP for that matter). If something is worth doing, its worth doing it right.

Regards
Boris Kraft

Comment by Bert Schulzki [ 03/Feb/05 ]

Beside this basic discussion what framework should be used,
I would like to add some concrete wishes for the current framework:

1. info.magnolia.cms.gui.dialog.DialogSuper.setConfig()
All Dialogs are hardwired here. If you want to introduce a new DialogControl, you would have to patch this method. There is a possibility to extend a custom control calles "include" (i have done this with fckeditor) but this makes configuration always a bit nasty, as you have to configure the path to the dialog jsp. If you could add "native controls" to this method (via configuration) you could simply canfigure controlType "fckEdit".

2. Dynamic Values for controls
I provided a patch in wiki to add the possibility of dynamic options to select controls. Please add this possibility as a general conecept to all controls (checkboxes, radiofields and even text...)

3. Consolidate constructors for info.magnolia.cms.gui.dialog.*
Currently two constructors supported: each with contentNode and configNode and one additionally with request and page context. I would suggest EACH control needs the request. The reason is, if you want to provide location sensitive default information, you would access to the value of mgnlPath, which is provided either as a request get parameter or in a formBean. With access to the request, (custom) controls can also share interact.

4. info.magnolia.cms.gui.control.* have package local constructors
These controls habe package local contructors - adding custom controls enforces the usage of the magnolia package. (see FckEdit class in its integration). It should be left to the implementers, which package they use, therefore the contructors should be made public.

Comment by Michael Aemisegger [ 03/Feb/05 ]

I strongly support Berts suggestions, especially 1. And I suppose also Andreas will.

Comment by Andreas Weder [ 03/Feb/05 ]

Well, partly. I'm the one asking for a slow, but well-made decision here.

I've previously asked for an easy way to validate control data. Well, at least for image sizes (the only time so far I really had to validate data handled by controls), I've found a much more cleaner and easier way to handle it than to patch magnolia. I'm always trying to not patch a system, if possible, but to understand the reasons and ideas behind it instead, then choose a solution, which integrates well with these. That's not always possible, especially if a system is not well-thought through, but something tells me that magnolia's ok in this regard.

So for images, I'm displaying them, even if they have wrong sizes, but I'm also marking them as being wrong-sized by displaying a red warning text and red border around them, and by showing them with default values (i.e. a maximum width and height).

Why I'm mentioning this here? Because I'm interested in a clean, consistent way we're going ahead here. If magnolia is about showing a user immediately, what a page will look like, why don't we also show errors in input there? Yes, it will cause some problems and oddities (we have to provide error handling not in the dialog, but around the page; plus the user may continue to publish the page anyway, thus you'll have to assume default values then), but the concept behind magnolia seems to be very well understood by our users so far, so I would hate it to see it being broken.

What does this have to do with frameworks? Well, some of them tend to be not well thought trough (Struts), plus it seems to me that the J2EE standard nowadays contains a lot of interesting building blocks. JSF looks promising. So if we choose a framework, or build a simple one ourselves, I vote for something building on these technologies. I agree with Boris that JSP is bad, especially if you embed too much logic in a page, and I'm also hesitant towards taglibs (ever had the feeling that a tag just didn't do what you actually needed?), but JSF looks good to me.

That's my $0.02 to the framework discussion.

Ah, one more thing. Let's wait what the integration of that workflow engine brings. I've got the feeling that it will solve quite some problems we're currently encountering.

Comment by Fabrizio Giustina [ 06/Feb/05 ]

work started on the dialog package. Still uncomplete, I will soon address completely at least the following:

1. info.magnolia.cms.gui.dialog.DialogSuper.setConfig()
All Dialogs are hardwired here.

Started refactoring which will allow in future to register custom control... still a lot to do

3. Consolidate constructors for info.magnolia.cms.gui.dialog.*

Done. To allow an easy configuration of new Custom Dialogs now only a no-args contructor is used. An init() lifecycle method has been added to the DialogInterface in order to set needed values.
Still need to cleanup dialog-specific configurations

Comment by Fabrizio Giustina [ 21/Jul/05 ]

assigning to Philipp, he is now the owner for this task.
Maybe we should analize the situation now and break the issue in different task or decline some of the proposal?

Comment by Philipp Bracher [ 22/Jul/05 ]

I read some Tapestry tutorials and will make a new statement about Tapestry vs JSF vs self-made. I think about restarting the arguing after the 2.1 final (just to get more traffic on the list

Comment by Philipp Bracher [ 24/Nov/05 ]

The refactoring is done for the first step. The next step will be made by magnolia 3.0. There are open discussions about how we wanna do this.

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