usecases.js cleanup...

[Jörn Nettingsmeier <po...@uni-duisburg-essen.de>]

hi everyone!


here's a first attempt at cleaning up usecases.js:
http://people.apache.org/~nettings/usecases.js

as you can see, i've put some repetitive stuff into functions and ripped 
out cforms-specific code. all other usecases work.

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.

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?

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.

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"
/>

where createContinuation and submitFlow are mutually exclusive.

this approach will also eliminate the cforms-specific code in UsecaseView.

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.

as always, comments and improvements appreciated.


jörn


-- 
"It's sad to behold how lately the wonderful English language has,
in the hands of corporate executives and marketing experts, re-
adjusted its prospective itinerary towards mythical subterranean
realms of discomfort, leveraging traditional woven containment
devices."

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: usecases.js cleanup...

[Jörn Nettingsmeier <ne...@apache.org>]

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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org