On Jan 3, 4:10 am, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> mmm....
>
> On Fri, Jan 2, 2009 at 2:06 AM, Yarko Tymciurak <yark...@gmail.com> wrote:
> > Hi Bill -
> > Sorry - I was sort of in shock when read my own comments (remind me not to
> > right when I'm tired!) - but I am glad you could understand them.
>
> .... to write when I'm tired!).....
>
> .....
>
>
>
> >> 2) Comments are not part of the model anyway and I don't see that
> >> replacing the 'col3' passed to SQLFORM with 'comments' passed from the
> >> view is a problem.
>
> > I think you are being too literal - comments as used are descriptive, about
> > the intent of the data item, and as such are about "form" not format. I
> > would not change this for now, focus instead on separating out the
> > commitment of data change so that there is explicit controller level control
> > - this is the clearest, most beneficial step. When that's complete, then
> > attack other parts.
>
> additionally, I would like to separate discussion about "label" and
> "comment" on model (and if there is or isn't a better way to express form)
> from what SQLFORM does or doesn't do with that, etc.
>
Just to clarify - when I say 'comment' I am referring to what SQLFORM
calls 'col3'. Am I correct when I say that the model doesn't
currently have a comment/cols3 attribute? It is just something passed
to SQLFORM. In my changes, I re-named 'col3' as 'comment' and have
used that name like everyone would know what I meant - sorry.
> I see these as distinctly separate topics.
>
> That is:
>
> - There is more to the form/shape of data - that is the model - than just
> data table definitions (e.g. there are constraints, descriptors, etc.);
> discussion of ways to represent this is one topic;
I agree that the model is more than db tables - I think of it as the
'business model' and hence stuff like validation rules should be
there.
So far I haven't used v.many tables in one app and it will be
interesting to see how to best accomodate large numbers of tables (for
maintainability). Is it just a case of 'including' files containing
groups of tables?
>
> - who is / should be dependent on (getting) and responsible for (changing,
> setting) the aspects of a data model is another topic. I think the most
> important part of what you propose to address is making interfaces for
> "setting" more explicitly in the controller spaces.
>
> - what constitutes presentation, and belongs there (formatting; presentation
> control logic; etc.) is also a separate discussion.
I would like a separate discussion re different forms of output (xml,
csv, etc) and how to generate them in a similar way to how html is
generated, i.e. with the ability to include logic but outside the
controller function. The current design where returning a dict can
only generate html output via an x.html template seems too narrow.
But I accept that html is the 99% need and TBH I haven't got a better
idea at the moment.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
