davebaird On terminology, I've got: driver, application, request,
action, command, Exported method, MVC, model, view, controller,
frontend, backend, workflow
teejay /msg me if you want me
davebaird Anything missing?
davebaird ok
* teejay would be interested in the definition of application vs driver
teejay vs controllor
davebaird Hah! Application is a woolly term, most closely related to driver.
pjsz__ synonyms right?
davebaird Controller is interesting!
pjsz__ that is app, driver, contrllr are .
davebaird I'll let you see what I've written when it's tidied up.
teejay application encompasses *everything* IMHO
teejay cool
pjsz__ this is a good list dave. What is command?
teejay driver vs controller is trickier unless they are synonyms
davebaird I agree
teejay but they aren't really the same
davebaird They're different, driver is the custom class you write i.e.
BeerDB.pm,
davebaird controller functionality is spread about a bit wider.
davebaird some of the templates call the action the command
kd on terminology, don't forget template.
kd and how to send things to the template to the exported method.
pjsz__ stash --
pjsz__ vs objects
davebaird template - good idea
davebaird stash - isn't that a TT thing?
pjsz__ display_colmns -- not really columns :)
davebaird Ah, I forgot, we added a stash accessor in svn
pjsz__ I've been using it heavily.
davebaird I think we can document display_columns in the module
davebaird Does stash need to go in a terminology section?
pjsz__ A lot of : Customer->new_trouble_ticket
pjsz__ the new_trouble_ticket action stashes the customer object then
redirects to trouble_ticket/create_new
davebaird I don't think a terminology section needs to document accessors.
davebaird They're documented elsewhere.
davebaird Any other potentially confusing terms?
pjsz__ I dont know. I guess not. Your right. Im OT
* davebaird has changed the topic to: docs, docs, docs
pjsz__ Configuration :)
kd Terminology can crossref to other parts of the docs. So stash can
be Xrefed to the appropriate place.
teejay regarding untaint, display_columns, etc
teejay I was thinking that would be the same kind of way to specify column types
kd untaint & co is getting into the realms of a glossary / index.
pjsz__ Also , how you use the CDBI Plugin Relationship is confusing to
me. I never could get it to work. Docs are so vague ther.
teejay kd, I mean you have a bunch of class methods you use to
manually provide metadata, and it would seem natural to specify
column/attribute types in the same way
* teejay talks on a different topic at the same time to confuse people :)
pjsz__ for display_columns it should be documented that it does not
have to be a "column". So i guess "column" needs to get defined in
the terminology
pjsz__ This could would go in the mode.
pjsz__ model.
teejay since we're talking about objects, surely column == attribute
pjsz__ column -- a real column in the table this class represents or
an accessor method setup by a relationship or
pjsz__ a method that returns a value or a
pjsz__ attribute or the madel class.
pjsz__ What is an attribute?
pjsz__ could we deprecate display_column in favor of display_attribute ?
pjsz__ I kind of like that.
teejay could make it an alias
teejay aliases are fine as long as they are clearly labelled in the
documentation and if you use them to not flitter between them and be
consistent
teejay so - how would you call column_types
teejay ?
teejay firstly would you do it perl model class, or describe columns
in mutiple classes
teejay s/perl/per/
pjsz__ column_type really is talking about a column. It just may be a
column in another table
teejay pjsz__, thinking about it, currently the mapping is very column oriented
teejay anything that isn't a column is treated or assumed to behave like one
teejay might be best to switch to using attribute later
kd column_type resolves the problem of columns which aren't really
database columns. Which is neat, as if properly documented it makes
it clear that the Maypole definition of column isn't quite the same as
the RDBMS definition of column.
teejay kd, indeed
teejay column needs to be defined clearly in the glossary, then we can
stick to using it consistently
davebaird I started separating them into columns (real columns in the
db) and fields (things that look like columns but aren't) in FB, but
it turned out to be a mistake, made things more complicated.
teejay davebaird, yep - thats what I would expect to happen
teejay better to make shit behave consistently
pjsz__ Thats why i was thinking "fields" would have been a better choice.
pjsz__ But now it may be too late and we are stuck with columns.
teejay indeed
teejay the underlying code and technology refers to real and virtual columns
teejay it would make sense that we have real and 'magic' columns that
behave the same
teejay much like in UNIX everything is a file handle, so you just make
stuff behave like a filehandle and everything is a bed of roses
pjsz__ I've been using maypole heavily last weeks before i get fired
for not using in past weeks and i am happy with columns. :)
teejay :)
davebaird I'm happy calling them columns, they're supposed to behave
like columns.
teejay yes
.......................
pjsz__ Any progess on Maypole form building?
teejay pjsz__, a bit
teejay it kind of depends on how column_types works
teejay and its unclear how to organise :(
teejay been building new apps in the hope of seeing how best the API should work
pjsz__ A couple of things i found recentyly :
pjsz__ I use to_select_from_many ( .. ) a lot.
teejay cool
pjsz__ I can pass it an array ref of objects as first arg or an accessor.
teejay I need to make all that work without CDBI::Plugin::Type
pjsz__ The accessor is to a has_many rel.
teejay cool
pjsz__ You do ? I thing you dont have to just yet. I think all you
have to do is say:
pjsz__ If you want this to work, you need to subvert plugin type.
pjsz__ with your own methods that work.
teejay pjsz__, it's too hard coded with cdbi stuff at the mo
teejay I really want to have Tangram working with it soon
teejay we need at least 2 ORMs to be sure the framework isn't too
closely tied to CDBI
teejay even if the other framework has to behave in a certain way
pjsz__ I'm pretty CDBI centric. ;)
pjsz__ Never used anything else.
* teejay has used Tangram and some inhouse jobbie here
teejay also wrote my own simple orm
pjsz__ Anyway, another thing about the way i have been using AsForm ,
teejay yes
pjsz__ I like to call methods in CGI format, ie:
pjsz__ call _to_select () , _to_foreign_inputs() .. directly rather
than going throug the to_field interface
pjsz__ When you are involved in relationships, to_field only works if
a column knows what it should do.
teejay yup
teejay makes sense to me
teejay they could easily be public
teejay and not require cdbi:p:type or other info
pjsz__ Exactly.
teejay I think that could be the way to go
pjsz__ to_cgi, to_field work great. And also they all work great by themselves.
teejay want to_cgi and to_field to use info from
asyetundecided->column_types(some arguments that aren't yet worked
out)
pjsz__ The way i coded it is that if the model->can('column_type')
try that. If that returns a type, use it. Otherwise , fall back on
CDBI Plugin Type. at. If it,
pjsz__ Seems natural to me.
teejay by model you mean thisclass?
teejay so should provide column_type accessor in Maypole::Model
teejay and set the values that uses via column_types
pjsz__ What arguments are you thinking column_type could take other
than the column name?
teejay which you'd call perl class?
teejay possibly read-only?
teejay which is already in asForm
pjsz__ Right. Buti i do not understand what you mean by perl class?
teejay sorry call *on* a class
teejay ie Foo::Bar->column_type or column_types
pjsz__ Right. AsForm already used column_type interface so i stuck
with it. seemed ok to me.
pjsz__ Problem i had was it did not work with IsA fields, enums, or bools,
pjsz__ Also it did not provide column defaults.
pjsz__ so i made it call the 'column_default' method on the model if
it can to get a default value for the element.
pjsz__ For some reason I get the feeling people think i am doing
something different in AsForm . I am not. I am just extending it to
where it was heading anyway.
teejay yup
pjsz__ IMO, it was incomplete but heading in the right direction
teejay yes
teejay is there a way to set column defaults in cdbi or maypole
teejay otherwise it might be worth having both a column_details method
and column_type and column_default and column_readonly
teejay where type/default/readonly are get/set accessor/mutators
teejay and details is a setter
pjsz__ In CDBI specific drivers there is .
teejay right
pjsz__ Yeah. it might be worth it.
teejay ok
teejay column_details would set multiple columns at once too
pjsz__ In long run i would say the whole damn thing needs to be
analyzed and mapped out real good.
teejay yes, been trying to do that ad hoc but not had long enough chunk of time
pjsz__ Me too. It would be fun to sit around all day and hack that out.
pjsz__ I hope i can do that sometime.
pjsz__ I think it should start with the General Model Classesś
interface to it's DB info.
teejay yeah
pjsz__ What is so surprising in that Thread that you mentioned is that
Tony talks about how he prefers to have info gotten from DB rather
than coded in the model, except, there is no interface to get DB info
in his CDBI model.
pjsz__ I understand that if you define it in the base but do not
implement it you make people specific on DB drivers.
pjsz__ But DBI does that doesnt it?
teejay I think he says he likes to have the choice
pjsz__ Why can't CDBI?
pjsz__ Maybe there are not enough specific drivers written?
teejay *shrug* there is no knowing with tony
teejay maybe that isn't cdbi's core job so its left to plugins/drivers
pjsz__ Anyway, tony is on the right track i think with objectifying
columns. Then you would just ask the column object what its
type/default/nullable/etc is
teejay yes
pjsz__ Has anyone written a Model for anything besides CDBI for maypole yet?
pjsz__ Another chang i made to AsForm was
pjsz__ to_hidden($obj)
pjsz__ it will hide this object in a hidden inpet with the PK name and value.
pjsz__ before I had to say to_hidden($name, $val)
pjsz__ the caller was always ignored. However now that i think about it,
pjsz__ if you have an object you want to hide in a form, why not just say
pjsz__ $object->_to_hidden;
pjsz__ And have it put itself in the form. If it has a multicolumn key
it could make an an input for each key and there would be an arryay.
pjsz__ in the params representing that object. For now i just start
with supporting single Pks
pjsz__ In Summary, i like _to_hidden to be called in 3 ways:
pjsz__ $object->_to_hidden; # hide caller in form
pjsz__ $self->_to_hidden($object) # hide object arg in form
pjsz__ $self->_to_hidden($name, $value) ; # make hidden with arbitrary
name and value
