| Justin Patrin 2006-04-26, 7:01 pm |
| On 4/25/06, Thomas Supercinski <thomas@corp.htcomp.net> wrote:
> Justin,
Please send replies to the list.
>
> Justin Patrin wrote:
> Agreed. Thanks for the reminder. I had at one time placed some code (va=
r
> declarations) within the generated code portion on another project, only =
to lose
> it later and sort of forgot that regenerating didn't replace everything.
> Please indulge a greenhorn, what are the issues involved that make extend=
ing the
> do's not such a great idea?
Because DO's factory method is the supported way to get an instance of
a DO and (IIRC) it doesn't support dealing with objects extended from
the base DO for a table. You *could* use one config for generating and
one config for production, making the config for production have an
extra part to the prefix...but this is just extra work for really no
extra flexibility, unless you're going to have multiple sets of
extended classes for different applications or something...
a[color=darkred]
of[color=darkred]
> I guess it could be possible to hack/replace the factory to use the 'cust=
omized'
> classes, but probably not worth the effort now or confusion it'd create l=
ater.
Yes, although switching the class prefix would also work.
> Using prepareLinkedDataObject works great. I should have seen that in th=
e docs.
FB's docs and options are copious, I don't even remember the specifics
of all of them at once. ;-)
he[color=darkred]
> OT - It seems there's pressure to do everything with MVC which isn't nece=
ssarily
> necessary, but it does seem helpful. Any other tips on getting at least =
closer
> to resembling MVC and still using FB?
Well, MVC is helpful in some circumstances, but there are other
options. Using FB doesn't break the paradigm *too* much. You put
"View" options (and sometimes code with the callbacks) in the DO
(Model) and FB does mostly "View", but also deals with data (Model).
However, the separation of M and V still works pretty well with DO
being the M and QF being the V. FB is just the glue between them (a
part of the Controller?).
But this is just rationalization really.
If you're worried about putting your View options in the Model then
you can set FB's options without setting them in the DO itself. There
are 6 or so ways toconfigure FB and these can be done in a couple of
different ways. See:
http://pear.reversefold.com/dokuwik...taobject_formb=
uilder:configuring_formbuilder
>
> I'm just beginning to refactor a legacy app built with no separation of
> _anything_ and no data abstraction with sql strewn all over the place, a.=
k.a big
> ball of spaghetti. I have a soft spot for pear packages because they see=
m to
> just work and I like the idea of small building blocks rather than a (usu=
ally)
> overgrown framework that, of the ones I've seen, don't seem as easy to pi=
ck up
> and use as pear packages or are not geared towards enterprise apps (I cou=
ld be
> very wrong on this). I've looked at many frameworks but none seemed to c=
lick
> with me. I assume you are fond of PEAR packages, at least to some extend=
, but
> do you have any suggestions as to options out there?
Sorry, I haven't really worked with any frameworks so I don't have any
suggestions for you.
>
> Thanks for the quick response. I hope you are doing well.
>
>
> Tom
>
--
Justin Patrin
|