I am working on embedding the editlive xml applet into alfresco. Not because I think we will end up using it, but as a proof of concept. So far so good. The trouble I am running in to multi-pronged.
First the logic for deciding what editor to use based on the mime type is codified in the CheckinCheckoutBean. As with the NewActionWizard it will probably be required at some point to relieve these objects of their case logic and put some sort of pattern in place that allows configuration to determine the outcome or action or whatever.
The second thing is that I am not sure that mime type alone should be responsible for choosing the editor (I'm not sure that it is.)
Consider the following. If I have an aspect or a content type that allows me to associate an xsd or a dtd to an xml, I may want to use an editor that can render a form.
If I just have an XML I want just an XML editor.
The big thing with all of this is that we move as much of the system to configuration. If we cant do that then we don't have a system that can be extended. Spring buys us a lot, but it's not the only game in town. We need to move the logic to patterns that allow configuration to define the logic. Pipeline / chain or command is a good example. Visitor in some case is another good example. These patterns need to be associated with configuration. For example, the form just executes the chain of command, the configured links carry out the work. Plug-in aught to be able to insert links in the chain. The more that is done in configuration the more extensible the system will be. Inheritance is a not a great solution in many cases, so overriding a class and putting the new class in the spring configuration wont work in those cases.
I'm not complaining, I think alfresco is awesome. It's evident that tons of thought and man hours have been spent on the system so far. Please don't missunderstand what I am saying.
Anyway, I'd be happy to get involved in this area or atleast strike up a conversation here or in the wikki.
any thoughts?
