On Mar 3, 12:26 am, "John M Camara" <[EMAIL PROTECTED]> wrote:
[snip]
> The SubView will be responsible for rendering a portion of a page
> which can consist of a form. The SubView will be connected to both a
> Provider to gain access to the database through an ORM and a
> SubViewDesigner which will have a default template and a number of
> processors that modify settings associated with the SubView. The
> MetaDataInspector will update the dataset and fields attributes on the
> SubView so that the SubView will know which fields will be returned
> from the data Provider. Other Processors will attach default
> validators and widgets to these fields. While other processors may
> limit the number of fields that are available to the SubView as in the
> FieldFilter Processor (you may not want to display all fields on the
> form).
>
> The SubView class will also have attributes for overriding the default
> behavior of the processors. These attributes can override the default
> screen names, default widgets, default validators, field display
> order, subview template, sorting rules, read/write access to fields,
> etc.
Ok, that make sense. So you will be able to define subviews in a
similar manner to other elements? i.e. declarative classes like
controllers/ORMs/Widgets?
eg.
class MyModel(ORM):
name = Column(Unicode)
...
class MyView(View):
provider = MyModel
fields = [...] # triggers field filter
order = '-name' # triggers sort filter
paginate_size = 10 # paginate filter
...
> A SubViewDesigner will have a default template and a number of
> Processors attached to it that are required to build a particular
> view. If you need an editable form for a record you would use a
> EditRecordDesigner. If on the other hand you want a read only view of
> a table you would use a ViewTableDesigner. All designers will have a
> default template for laying out the view but this can be overridden by
> setting an attribute in the SubView (not implemented at this time) .
Ok. Still not quite sure what the difference/needs are between
SubViews and Designers. Are they not just specialisations of SubView?
Default base configurations? Why the 'Designer' naming?
> > I'm not sure of the purpose of a view builder, other than the obvious
> > building of views :)
>
> The purpose of the ViewBuilder is to take multiple SubViews and
> combine them in on page.
OK. What's the advantage of this approach over a normal template?
Could you give me an example as to when a ViewBuilder might be used?
> > How much provider integration will the subview processors have? e.g.
> > for sorting you want to be doing that in the DB ideally, not in
> > python. I guess the depends on what operations you provider supports.
>
> The sorting will be done by the database. Each provider will be
> responsible for looking at the appropriate properties of the SubView
> to convert them into something the ORM can handle.
Cool, so providers have relatively rich functionality. Good.
> > Also, what about controllers/dispatch in general?
>
> This can be done at a latter time once the system is functional.
> Initially you can just import DBMechanic and than add SubViews or
> Views as class attributes to you controllers. Then in your expose
> methods you could either return the results obtained by calling the
> render method of the SubView or you could pass the results to the
> dictionary that is passed to the template provided to the expose
> decorator.
I guess this makes the most sense, as dispatch is so app specific. Are
the views going to be widgets themselves, or provided as a widget
somehow? I would like to pass widget instances to my page templates if
possible, rather than pre-rendered HTML.
> Hopefully this is of some help for now until better docs can be
> provided.
It's great thank you! Thanks for taking the time to explain it all. I
think I need to get on with building something ASAP, but I can look at
fudging the provider/processing for now, and concentrate on widgets
that may be more useful to contribute at a later date.
Is the main repository in the tg svn pycon branch, or is there some
other repo somewhere?
Thanks for your time, am definitely interested in getting involved
with future development.
--
wavy davy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
