Leszek Gawron <[EMAIL PROTECTED]> writes: > This would be quite long, sometimes OT but I think it will > finally get to my point which is: providing persistence in > flow by basing only on O/R tool is not enough.
I think this depends on what you mean by an O/R tool? Clearly (with SQL 3) O/R mapping is possible in all cases. Having a tool do it for you automatically may not be possible. > OR mapping tool is OK if you have got a _static_ database > schema but imagine you have to write an application that > collects questionnaires. Been there, done that: O/R mapping still works fine; just don't assume a static schema! dynamically manage your metadata... <snip on partially normalized schemas/> > You want to write an application using flow and other cocoon > possibilities > because: > a) you will have to provide a user with interface for all > of this - flow is > the sore for your eyes > b) you will have to generate some reports/statistics and so > on - pipeline > processing would make it real fun You forgot one: you have to present each "questionnaire" in a customized fashion for many different user groups.... > 1. I CAN BET MY ASS THIS IS IMPOSSIBLE TO MODEL WITH ANY O/R > MAPPING TOOL. A 5th normal form schema that normalizes out redundant relationships is a real pain to map back to an object model. I'm not sure you can do it automatically. At the moment we've decided to use EJBs. However, you're example so far comes from the relational side instead of the object side. What's the Object Model? Only once you have an object model do you know if you can do a OR mapping (the other way is a RO mapping, whatever that might be?)... > 2. Even if there is (I'm gonna have to live without my ass) I > do not really > think it is going to be any useful (and/or efficient) for > advanced reports > (and there's a loooot of statistics to make if you just > add some more > parameters to all this). The schema can do just fine. The mapping, I'm not so sure about... > 3. the only thing cocooners say till now is: use OR mapping > tool with flow, otherwise > you break SoC, you will burn in hell! :) I don't think anyone has said that. True the discussion about EJBs (for example) has been limited, but it pops up every once and a while... > You say: that is not something that should be built on cocoon. > I say: cannot be more wrong - suppose the main purpose for > this all are web reports and statistics? > > So the real question goes here: > Is there a clean way (in terms of SoC and all that stuff)? Well, again, I think you need to produce the Object model before you conclude that OR mapping isn't going to work. At that point, you may determine that Session Beans are a better alternative (essentially a manual mapping). Complex models require complex solutions, but so far I'm not sure that the problem you are proposing is really all that complex? > and the conclusion goes here: > Not everything can be implemented with OR tool. Even if it > breaks SoC maybe it would be worth to provide developers with > some not-so-clean-and-elegant replacement but working instead. I'm not quite clear on why you associate breaking SOC with any non OR solution? > You can always do it the hard way (prepare generators and > transformers talking to database directly through JDBC), but > maybe there is a cleaner way i do not see. > > What do you think? Hooking EJBs into flow should start to emerge as a more general Cocoon solution in the next couple of months. IIRC it was exactly this requirement that drove much of the discussion on generalized flow in the first place (about 3 or 4 months ago, not the recent discussion). > Hope it's not just wasting your time. No such thing in Open Source: if we decide to response it's our choice, worst case is you waste your time writing something (no one responds), but you still haven't hurt anyone (unless you start spamming the list)...
