[jifty-devel] RE: [Jifty-commit] r2859
- in Jifty-DBI/trunk:lib/Jifty/DBI
jesse at bestpractical.com
Thu Mar 1 12:57:38 EST 2007
On Thu, Mar 01, 2007 at 12:47:59PM -0500, Edgar Whipple wrote:
> We might want to expand that to include different presentations. For
> comparison, here is a list of field types from a certain Other Web
Sure, though I think that our types specify a default rendering (which
is how it happens now) and let the user override if they want an
alternate presentation, even if we happen to ship more render options.
(Again, as it works today ;)
> -- A good, flexible set of baseline type/column definitions might go a
> long way toward lowering Jifty's first-use barrier.
No argument there.
> -- I'm thinking even more that pluggable U-D type definitions would be a
> Good Thing.
> -- If we implement user-defined types, we can expect at some point
> people will produce modules that do nothing but provide collections of
> type definitions for columns, records, and/or tuples. Jifty already
> accommodates that, but I have specifically in mind the publishing of
> CMS-related *components* that don't do anything by themselves. There may
> be additional concerns, especially in namespace-related decisions.
> -- The J::Plugin pod says "Actions and models under a plugin's namespace
> are automatically discovered and made available to applications." Can
> this accomodate partial models? (The question might make more sense
> after post about "composable node types".) (I confess I haven't looked
> into Jifty's existing plugin features yet.)
I'm in the middle of turning this from "sucks" to "works". I don't
think we'd want to model user types as partial models, though both
should be supported. See my last couple commits to the template-declare
branch of jifty. (and no, there's no good reason the work is there,
rather than on trunk)
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
More information about the jifty-devel