Hi John,
This is a bit of a long winded answer, I apologise for that.
On Wed, 2006-06-14 at 12:54 +0100, John Stewart wrote:
> OK, I've refined down what I'm trying to do.
>
> I'd like to keep this as MVC as possible, so the Java code should not
> deal directly with the alternative styles, though It will provide the
> logic to select the styles.
>
This is just my opinion and it may not be "correct" as far as some of
the more experienced developers will say. So take this however you like.
Ignore it completely if it doesn't sit well with you. Or shoot it down
if you would prefer. :)
Personally I think this is being way too anal about MVC for no really
good reason(that I can see anyway). I think its probably a mistake to
take a hard line and say that WOComponent subclasses are only the
controller. IMO it's valid to say that a WOComponent is, or can be
View. After all, a WOComponent+wod+html together are responsible for
generating the view - look at the api of WOComponent and you will see
this is the case. eg) appendToResponse. on the other hand WOComponent is
also controller thanks to pageWithName.
I think that stateless components also provide a good argument to say
that WOComponent should not be relegated to Controller only. I mean,
they don't have to do anything but view. Not to mention you can create
WOComponents that have no HTML at all and generate the entire response
in code. Probably not the best idea but it is possible regardless.
I think the really important point in WO is to always ensure that
WOComponent subclasses are never Model(bussines logic) in MVC. You will
be very pissed off when you have to move logic from a WOComponent to
reuse elsewhere. Copying the logic is not acceptable. Putting the logic
in a superclass is not really acceptable unless it passes the is-a
test.
>From experience, I can say it totally sucks when you have logic in one
component that you want to invoke but you don't want to call
pageWithName as it screws with the context(the context returned from
context() method of WOComponent that is).
In the past I have had trouble figuring out if WOComponent is C or V in
MVC. I now think it can be either or both. EG) some WOComponents can be
built as View components only while others can be more of a Controller
type of component and some are a mixture.
AFAIK The whole point of MVC is reuse and clean separation to support
reuse. How taking the class name for a css style out of the WOComponent
will allow for a more reuse I don't see. If you are building a nested
reusable component you simply provide a binding for the class name and
the parent component or some other object supplies the class name at
runtime or you can just stick it in the wod if you know it wont change.
> The simplest version of this is a straight boolean describing "open"
> or "closed" styles. The java code can, say, provide a boolean
> "isOpen".
>
> If I create a ul wrapper "styleContainer" as below, I'd like to
> include the "open" or "closed" styles, as well as a common "clear"
> style.
>
> The output would be of the form:
>
> <!-- isOpen = true: -->
> <ul class="clear open">
> <li>...</li>
> </ul>
>
>
> <!-- isOpen = false: -->
> <ul class="clear closed">
> <li>...</li>
> </ul>
>
> Any ideas how I might do this without providing explicit class strings
> in Java? Can a WOConditional be nested inside a WOGenericContainer
> definition?
>
> I could wrap the two versions inside two WOConditionals, but then it
> would mean duplicating the whole list.
>
Sure, but this would meet your MVC requirement. Although it does have
some pretty serious drawbacks.
> To further complicate things, what if I want more than 2 alternative
> styles, e.g. fed by an integer instead of a boolean?
>
> Or is this one of WO's limitations where I have to include style
> names
> in the Java code?
I don't think its a limitation of WO but rather one of the strict(and
possibly misguided) approach taken as far as MVC is concerned.
You have already listed an alternate option above. You will just end up
with a mess in your WOComponent of nested conditionals. IMO its much
better to relax your rules about MVC and put the class name in the
component; after all you have stated that the logic will be there!
If you want to change the style change the css - no big deal right?
However there is another option that I can think of, and that is set the
styles using Javascript.
Your script might look like:
//This would be an integer returned by the class logic or a string or
// whatever identifier you want to use.
var classToUse = '<webobject name="classIdentifier"></webobject>'
//invoke this somewhere to set the class.
function setClass(){
var class = (classToUse == 1) ? "open" : "closed";
document.getElementById("myList").class=class; //whatever this is..?
}
<!-- html content -->
//set the style.
setClass();
Off the top of my head I don't know what the problems with this approach
will be, if any. I think this will work.. YMMV.
I hope that has helped in some way, shape or form, and if it hasn't then
pretend someone else wrote it! ;)
regards,
- shaun
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
