Jörn Nettingsmeier wrote:
hi everyone!
here's a first attempt at cleaning up usecases.js:
http://people.apache.org/~nettings/usecases.js
new version (patch against current trunk) is here:
http://people.apache.org/~nettings/usecase_cleanup-breaks_cforms_atm.diff
features:
+ rips cforms-specific stuff out of the core code
+ makes usecases.js fun to read
+ makes UsecaseViews.Java fun to read and adds documentation
+ seems to work ok for all usecases except cforms.edit with some
backwards-compatibility glue.
- breaks cforms, because the flow snippet insertion is not yet implemented.
here's how the xconf view declaration might look:
<view uri="/modules/foo/usecases/foo-mogrify.jx"
loopFlow="/modules/foo/flow/mainLoop.js"
submitFlow="/modules/foo/flow/submit.js"
menu="false|true" createContinuation="false|true" />
this is now implemented, although the *Flow attributes are currently
non-functional.
as to cforms, i'm planning to add a generic solution for custom
flowscripts, inspired by the existing mechanism of <intro/> and
<outro/>, which should be ok for cforms. if it works out like i think
it should, you will be able to pass two urls with custom flowscript
snippets to the usecase declaration - one for the main loop, and the
other for the "submit" case.
this is a little harder than it first looked.
looks like i need to replace the entire
usecases.js::executeUsecase()::showView() and advance() functions with
custom code, because forms do not easily map to cocoon.sendPage (that
would bypass the entire Form.js code)...
i decided against reading the code from the <view> configuration,
because that would make it a build-time thing, which is horrible for
debugging. instead, i'd like to put URIs in the loopFlow and submitFlow
attributes which should point to text files containing javascript
snippets. these are transformed into functions in usecases.js:
source = resolve(loopView)
f = read source
customShowView() = new Function(f)
source = resolve(submitView)
f = read source
customAdvance() = new Function(f)
that way, they can be changed at runtime, unless i'm overlooking some
hidden caching issue.
wdyt?
i'd also like to get rid of the duplicate view methods (<view
template=""../> and <view uri="".../>). both do almost the same now
anyway. the remaining one (i'm favouring "uri") will take a
protocol-less uri that will be fed to the root sitemap if it starts
with a slash, and to the usecases.xmap if not. this will make our
framework consistent with the cocoon documentation. any objections?
i would like to formally deprecate the <view template=""/> attribute in
favor of <view uri=""/>. uri must not contain a protocol (for
consistency with sendPage/sendPageAndWait) - it will always be resolved
like "cocoon:/", i.e. if you don't use a leading slash, you end up in
the usecases.xmap, and if you do, you go to the root sitemap.
any objections?
in my patch, there is a compatibility hack that will map template="" to
the same view field as uri="", and usecases.js removes any old
"cocoon:/" protocols and logs a deprecation warning.
doug has recently requested an option to switch from sendPageAndWait
to sendPage, to cater to one-shot usecase views. is that a purely
hypothetical scenario, or will people use it? i can add an option,
but i'd like to avoid creating dead code.
the switch is in. if you set createContinuation="false", then the
usecase framework will use cocoon.sendPage() and immediately call
cocoon.exit() afterwards.
if anybody is using custom variants of the cforms module for some
more advanced stuff, i would be glad to hear about them, in order to
find out about limitations in my outline.
this question still stands.
i'd welcome feedback.
regards,
jörn
--
Jörn Nettingsmeier
"Hofstadter's Law: It always takes longer than you expect,
even when you take into account Hofstadter's Law."
- Douglas R. Hofstadter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
