|
|
Posted by klenwell on 10/03/07 16:49
> > Thanks for that Jerry.
> > I was trying to keep things simple (!).
>
> Yea, but it's not always that way, unfortunately.
>
> > At the moment I have 'design' and it does everything, but it has 30
> > odd methods
> > and I wanted to see if I could make things easier to manage. The idea
> > was to have
> > inheriting classes 'cushion', 'blind', 'pelmet', 'curtain' and so on
> > (it's a soft
> > furnishings site) where functions relevant only to cushions (or
> > whatever) would be
> > in the child class.
>
> OK, that's reasonable enough.
>
> > The reason I need to call design without knowing its type is that it
> > has to speak up
> > for itself in the shopping basket page.
>
> > Mind you.... it works at the moment, so maybe I'm only making grief
> > for myself.
>
> > Thanks again.
>
> > Pete
>
> I suspect everything's in a single class right now, and some methods are
> applicable to one object while not another. This would be a great use
> of inheritance.
>
> What I might recommend is to use the static function idea in the
> 'hanging' class. Maybe pass it a database row id (or the contents of
> the row, if you wish) and have it build the appropriate class from the data.
>
> As I said - it's not perfectly clean, but if you want to use
> inheritance, someone needs to know what the classes you're using are.
> And keeping everything in this one function means you can easily add
> more classes to the inheritance hierarchy later.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
Pete,
I was wrestling with much the same issue recently with a form library
I'm developing. I wanted there to be a Form class which would be
responsible for managing all the elements in a webpage form and a
FormElement class which the add_element method of the Form class would
use to construct child object elements of specific form field types
(e.g. ElementTextInput, an extension of FormElement).
It doesn't involve a database, but I did want to validate element
types against a central array. For that I ended up using the idea
Jerry suggested here: a static method in the base element class (I may
move it to the form class before I'm finished) that can be called
statically to retrieve a valid list of element types:
function get_valid_types()
{
$V = array(); // return
// element families
$V['INPUT_TEXT'] = array('input_text', 'input_email', 'input_url',
'input_password');
$V['TEXTAREA'] = array('textarea');
// all elements
$V['TYPE'] = array_merge($V['INPUT_TEXT'],$V['TEXTAREA']);
return $V;
}
So if I add a new subclass (say, a radio-button menu class), I can
just update this method.
Like you, I originally was dreaming of something simpler and more
elegant for the library as a whole. The resulting code ended up being
more complicated and required an additional Factory class to make
everything work as transparently on the API end as I wished. But once
I got that sorted out, implementation is pretty simple:
$TestForm = new CeoForm($debug);
$TestForm->add_element($name='text_input', $type='input_text',
$label='input some text', $is_required=1, $maxlength=255,
$minlength=4);
$TestForm->add_element($name='email_input', $type='input_email',
$label='email address', $is_required=1);
$TestForm->add_element($name='url_input', $type='input_url',
$label='web address', $is_required=0);
if ( $TestForm->is_valid() )
{
// insert results in db or whatever...
}
else
{
$show_form = 1;
}
Anyway, your problem strikes me as the same basic problem. If
interested, you can view the source for this library here:
http://klenwell.googlecode.com/svn/trunk/PHP/ceo/php_ceo/ext/input/
Tom
Navigation:
[Reply to this message]
|