[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:
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, |
| 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 |
| Comment by Bert Schulzki [ 03/Feb/05 ] |
|
Beside this basic discussion what framework should be used, 1. info.magnolia.cms.gui.dialog.DialogSuper.setConfig() 2. Dynamic Values for controls 3. Consolidate constructors for info.magnolia.cms.gui.dialog.* 4. info.magnolia.cms.gui.control.* have package local constructors |
| 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 ] |
|
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() 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. |
| Comment by Fabrizio Giustina [ 21/Jul/05 ] |
|
assigning to Philipp, he is now the owner for this task. |
| 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. |