On Mon, May 22, 2000 at 05:19:50AM -0400, Chris Kimpton wrote:
> I'm trying to handle the situation around basic maintenance forms for
>inserting/updating objects, such as User. That is on first showing a screen/form for
>a new user, the fields are blank, then on completing some invalid details, the
>screen/form is redisplayed with the details supplied by the user and the bad bits
>highlighted. This is needed in a similar fashion for the update case too.
>
> Code like this in my screen;
[snip ECS stuff]
Have you considered using webmacro templates for this? I know Jon has
done some for user/security management in Scarab that I'm sure he
wouldn't mind you plundering :-)
He uses a common include file in the templates to eliminate duplication
of the actual form definition. This way you have very HTML-like template
files that control the appearance of your pages.
> Where AttributeItem defines things like the label, name, type, mandatoriness of an
>attribute.
>
> The AttributeType then has subtypes like FreeFormString, PasswordString and
>EnumerationString (for a fixed set of values).
I do like this idea. Tools that could be stuffed in the
webmacro context to do this stuff would be great ;-)
> You could consider using the setProperties method I added to
> > ParameterParser instead. This will match parameter names to
> > setXXX
> > methods for you.
>
> I've now had a quick look at this method - it looks useful for
> the "setting" side of things (that is *4b*).
>
> So *1* becomes
> data.getParameters().setProperties(mem);
I'd definitely look at having a generic 'validate' method in the mem
baseclass that you pass the RunData instance to so it can generate
messages to return to the user if the validation fails (something I've
banged on about here before :-) )
> [Although I would now need to write setters for all properties - and I'm lazy :-) ]
IMO writing proper object wrappers around your database attributes is a
key to clean separation of model from view/controller. That way you can
absorb changes in the underlying data model without altering view or
controller code. You also get more compile time typo checking, although
granted you're not exploiting this when you use 'setProperties'.
>
> On the "getting" side of things, I'm not sure how I would handle the differences
>between simple text fields versus combo boxes and lists. Perhaps I'd provide a
>getHtml type method for the whole object and it would (via some utility methods) just
>pull out all the details, such as;
>
> The screen becomes
> ecsPageFormPart.addElement(mem.getHtml());
Yeah, I also thought about something like this. It has a pleasant
polymorphic appeal, but I think mixing what is essentialy a 'view'
decision in there with the data modelling objects is wrong.
For instance, imagine you want to implement a new user "wizard" which
breaks the process down into a series of screens. In that case the HTML
you want to generate for a given list (say Roles) may want to be
different - a bigger <select> say. Then you end up having to write
class-specific screens anyway.
>
> So - maybe my suggestion is not needed then.
>
> I like this from the point of view, it keeps the attributes as full attributes.
>
> I don't like it from the point that we already using hashtables for some generic
>data - so why not do it for all and use methods that work on the hashtable, rather
>than methods per attribute. I guess I still need at least a line per attribute -
>even just to create it as an attribute item.
If you're convinced you don't want to write get/set methods then you
could do a couple of things; you could make the string keys into the
hashtable class constants of TurbineUser to get the compile time type
checking.
And then you could derive all the classes where you want generic access
to the hashtable from a single superclass that is itself derived from
BaseObject - this would leave BaseObject as it is, but give you the
generic access you'd like.
Having said that I _do_ think that writing business objects with get/set
methods that encapsulate your underlying data model makes sense. It
makes the implementation of special behaviour for certain attributes
very easy and error-free.
Sean
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
