Am Donnerstag, 14. Juni 2007 schrieb Philipp Bracher: [...] > > There is a history page where I document what is going on. As you > > can see, next step is reworking parts of the gui.
Updated. > Do I understand correctly: the GUI is not working anymore in general > and not only for your custom modules? No, the gui works (again) with my sanitize patches for ids and names. Some Dialogs/Controls (at the moment I know the one in DMS) are still broken. > Any symptoms? Probably small things I think. The problem I described in "Dialogs and Controls, HTML/JavaScript, use of FreeMarker", 2007-05-11. > > I have at least two* modules which use custom node types and > > namespaces. After > > refactoring them (move into magnolia package namespace), I will > > provide them > > as fully working examples. > > The bad part is the gui (controls, dialogs). > > Without having a working backward compatible GUI we won't be able to > apply the changes to the trunk. I patched the gui but I'm not happy with its actual state: 1) HTML ids and names and JS function names are created from property names which could contain illegal characters and render HTML/JS invalid The sanitize function from StringUtils fixes most of the problems replacing illegal characters with an underscore and prefixing the name with mgnl_ (when it doesn't start already with mgnl, see comment in StringUtils). This method is not 100% save. Think we have similar property names: prÖperty and prÜperty*, both result in mgnl_pr_perty. It might be a rare case but I don't want to rely on it. It will break sooner or later. (*) I know the gui prevents entering/saving special chars. But what's about import/export or exchange with other (content management) systems? A better solution would be to hex-encode the names. It's saver but leads to unreadable names which makes it harder to debug. We could swap implementations of sanitize when debugging - not optimal because we also slightly change the system behaviour (another potential cause for bugs). I have to review the JS and check if they make use of the property name to construct the id/names of HTML elements for accessing them. If it's the case, sanitize has also to be implemented in JS. 2) mixin of Java and HTML/JS it's ugly, it's unreadable, it's unmaintable - should be done with FreeMarker > > I don't like doing rich guis in > > HTML/JS. Maybe I drop that and rewrite it in Flex[fx] (ActionScript/ > > MXML) and > > leave the HTML (FreeMarker) port to someone else. > > Depends on your project. But the more you diverge from the current > project, the more merging problems will come up in the future. Yes, I agree with you on that. It will not happen as I do regular merging with trunk. I know that the Dialog/Control stuff should be rewritten, but there is no decision yet, is there? For now I can live with the gui as is when all Dialogs/Controls work. I have no time to move them to FreeMarker at the moment. I need client-side sorting and filtering for the product module. A long list with all items is just not convenient. I don't know how to do it with the current Dialog/Control framework, but it could be done with Flex and E4X (EcmaScript for XML) very well. > > But then I have to think again about a _general_ solution to > > decouple Content > > from the repository (which we also need for WebServices). I did > > some basic > > tests with XOM, > > OK > > > but I think the ObjectContentMapper from Graffito which was > > imported into Jackrabbit could be a better solution. > > Seams to be a solution. But looks like having a big overhead for > defining mappings. > > Did you check the spring modules JCR persistence? I took a very quick look at it. There should be a decision if we depend (partial) on Spring or not. I can't think of any cons now (beside using Spring is trendy ;) but some pros: - we don't have to implement a lot of functionality ourselves - using Spring could attract more developers - should be easier and more standardized to integrate functionality (e.g. WebServices with XFire) - the module framework isn't mature yet (deinstalling, runtime de-/activation), maybe Spring OSGi is a solution > > Let me know what you think. > > Would be nice if we can find a conclusion on that topic once. Since > we want to use POJOs in magnolia, we need a general approach for the > main project itself. The first step is done with the content2bean > package. Writing bean2content would be rather trivial, but I'm not > sure if this would be a good approach. > > The question is what should we use: > - content2bean > - xstream > - graffito > - spring module > - ... This question sounds a little provocative: Do we need Content as Beans? The direct support for XML (native) in Java is getting better, same on client-side with E4X. JCR --> Content --> Bean (--> XML) or drop intermediate Bean and work with XML JCR --> Content --> XML We don't have to unmarschall/marshall when using WebServices, our Content is already XML. It would also be my preferred format for importing/exporting instead of verbose JCR system view. Next step is providing a sample module which makes use of all new features so everyone can play with them. It would live in community as magnolia-module-sample-$name. O. ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/docs/en/editor/stayupdated.html ----------------------------------------------------------------
