On Fri, 2005-08-19 at 10:08 +0200, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
>
> > + /**
> > + * @return Returns the useCforms.
> > + */
> > + public boolean isUseCforms() {
> > + return useCforms;
> > + }
>
> I'd rather make this more general:
>
>
> <usecase ...>
> <view type="cforms">
> <cforms definition="..." binding="..."/>
> ...
> </view>
> </usecase>
>
>
>
> public static String VIEW_JX = "jx";
> public static String VIEW_CFORMS = "cforms";
> public static String VIEW_FOO = "foo";
>
> public int getViewType() {
> return this.viewType
> }
>
>
> Maybe we can use a ViewHandler class or something else
> to use polymorphism instead of static fields and an if/then/else
> condition in usecases.js?
>
Yes, makes sense. The patch was just a prototype implementation where I
did not wanted to change the architecture. A proof of concept. ;-)
> JavaScript is interpreted, so we can even create function
> calls dynamically.
>
Actually right now that is not necessary because we do not need a
different flow for cform then for jx.
>
> function cformsView(...) { ... }
> function jxView(...) { ... }
> function fooView(...) { ... }
>
That leads me to another extension of the usecase-fw: custom flow. With
the approach you recommend I see a way to enable custom flow scripts
into the usecase-fw. :) Good on ya, mate.
> ...
>
> eval(usecase.getViewType + "View(...)");
>
>
> That is IMO cleaner than if/then/else.
>
+1
I am on vacation now and have some friends over here from Germany. I
will not be able to work on this till Monday night. If you are faster,
then be my guest. ;-)
>
> -- Andreas
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
