[flatland-users] Possibility of using Formish widget library?

13 views
Skip to first unread message

Tim Parkin

unread,
May 18, 2010, 9:18:01 AM5/18/10
to flatland-users
Hi,

We're looking at overhauling the formish data layer and found flatland
and are pleased to see that the approach you've taken is compatible
with the way we've developed formish. I was wondering if you'd be
interested in cooperating in some way. I was thinking about some way
of using the schema/validator/data system from flatland combined with
the form/widget handling part of formish?

Thoughts?

Tim

--
You received this message because you are subscribed to the Google Groups "flatland-users" group.
To post to this group, send email to flatlan...@googlegroups.com.
To unsubscribe from this group, send email to flatland-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/flatland-users?hl=en.

jason kirtland

unread,
May 20, 2010, 12:52:05 PM5/20/10
to flatlan...@googlegroups.com
On Tue, May 18, 2010 at 6:18 AM, Tim Parkin <in...@timparkin.co.uk> wrote:
> Hi,
>
> We're looking at overhauling the formish data layer and found flatland
> and are pleased to see that the approach you've taken is compatible
> with the way we've developed formish. I was wondering if you'd be
> interested in cooperating in some way. I was thinking about some way
> of using the schema/validator/data system from flatland combined with
> the form/widget handling part of formish?

Hi Tim,

That could be a fabulous pairing. Widgeting is something I'd like to
support for flatland but I've been hesitant to implement it in the
core. But something I've long thought flatland could provide pretty
easily is a solid API to associate schema elements with widgets or
whatnots- a backbone that formish, gtk, other widget systems and even
things like SQLAlchemy mapping -> schema tools could use to handle
lookups.

I'm not sure what that API would look like. It probably needs some
prototyping and sketching. The ancestor-traversing discovery aspect
of the I18N implementation could be a nice way to allow widgets to be
associated with individual elements and also provide a path to acquire
a type->widget mapping as a fallback. Unfortunately the I18N required
some properties to be added to the base Element, which I'd like to
either avoid for widgets or implement as a single extensible point for
widget systems to manage and store configuration data.

I'd love to hear any thoughts on how that might work. I'd imagine
you've covered that ground in the schemaish -> formish bindings?

-J
Reply all
Reply to author
Forward
0 new messages