On Mar 2, 4:18 pm, "wavydavy" <[EMAIL PROTECTED]> wrote:
> On Mar 2, 9:42 pm, "percious" <[EMAIL PROTECTED]> wrote:
>
> > I am working on the team developing the "dbstuff" apply named
> > DBMechanic for the time being. It is intended to be a replacement for
> > FastData.
>
> OK, cool.
>
> > Please excuse the blurry documentation. The intention is for that to
> > be a place holder for a graphical document which should be available
> > in the next week.
>
> It helped me understand a little more what you were trying to do,
> anyway. Good to know there's documentation in the works.
>
> > The truth is, the code base is in a state of flux at this point, but
> > by mid-end of next WEEK we will need developers in a bad way. We too
> > have a short time-scale and need something up and running ASAP.
>
> Good to know.
>
> > What we plan to do is finish sorting out the basic API and get SQL
> > Alchemy and ToscaWx support sorted out before unleashing this to the
> > droves of developers gnawing at the bit to get their hands on it. Ha
> > ha!
>
> Well, I could be one of those, for sure :)
>
> > Seriously though, we will need all the help we can get to develop
> > the Widgets to support the API base as soon as we get the general
> > schema worked out. We hope to have this by Wednesday of next week, so
> > if you can hold on till then we could really use some help.
>
> I may be able to wait until then, there's plenty of other
> bits'n'pieces I can be getting on with. I'd be happy to help with some
> of the widget work.
>
> > In the mean time I am happy to trade email/message board posts about our
> > project. Ask away.
>
> OK :)
>
> So, a provider is a uniform way of performing crud-type operations on
> a data model (SO,SA,etc), right? Fair enough, a standard and needed
> approach.
>
That's correct
> OK, you can define a subview on your data, which is a list of
> processors that can manipulate your data in some way. Is that right?
> Is this designed to be processed/optimised/cached in some way? Some of
> these processor can be widgets, right?
>
> You can do this via a subview designer, which is what? An api? A gui
> tool? These seem to be aimed at providing record and list (table)
> views, but what is an admin view or filter view?
>
Once additional code is written and the structure stabilizes I will
put together a better document that describe the system. But for
now..
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.
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) .
> 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.
>
> Overall sounds a potentially flexible system, if a little complex :)
>
> 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.
> 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.
Hopefully this is of some help for now until better docs can be
provided.
John
> --
> 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
-~----------~----~----~----~------~----~------~--~---
