Andrew C. Oliver wrote:
-1 business logicTotally agree.
+1 flow logic
I think one of the reasons I got so uptight about flow was the misuse of the term business logic. Business logic is the big stuff you do backended just before it goes to the database. Such as debiting a customer's account and crediting sales. Workflow logic is still presentation logic. Such as "Gee he just pushed 'preview' on the 'design card for my girlfriend' page, lets make sure he didn't leave and fields blank and if he did, send him back with an error, otherwise send him to the preview greeting page". . Thats not business logic.
We can't stop people from abusing the flow, but we can make it *harder than ever* to write complex stuff in the flow (because the object model will be very limiting) and easier than ever to delegate complex logic to the java objects (for example, the Cocoon object exposes the avalon component manager).
Sticking business logic (like connection to EIS systems and crediting and debiting accounts should not be done in flow). Perhaps pushing the FLOW to go to things that DO that should, but not that actual stuff...Hmmm, no, it's not a must. It might lead to severe sitemap abuse. We must think more about this.
why should they have to be in sync? it might be a totally different
flow.. If we could read the flowscript from an internal pipeline we
would be set.
<map:flow language="JavaScript">
<map:script src="cocoon://something/prefs.js"/>
</map:flow>
Yes this is an absolute must.
Andy, before getting vocal about something, you should start to understand what we are talking about.sticking it all in a monolitic sitemap is setting back CS by about 30 years.
nobody said anything about includes in the scripts. Here, we are talking about *how* to connect the sitemap with its flow. We have to decide whether or not it makes sense to have more than one flow connected to a single sitemap and if it makes sense to have it dynamically choosen with sitemap parameters or even if it makes sense to give the ability for cocoon pipelines to generate the script file dynamically.There is nothing wrong with includes so long as they're clear.
The above tells me where to find the JS. I think however it might be best constrained to the sitemap. Meaning a JS shouldn't be able to include others. (That does introduce a limitation but makes life more readible).. But I'm not sure on this...Discussing inclusion in the scripts is another concern. Let's work on one at a time.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
