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.

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?

I'm not sure of the purpose of a view builder, other than the obvious
building of views :)

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.

Also, what about controllers/dispatch in general?

--
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to