Wichert Akkerman wrote:
> Martin Aspeli wrote:
>> Wichert Akkerman wrote:
>>
>>> Previously Martin Aspeli wrote:
>>>
>>>> However, there are a few things that I am quite sure about:
>>>>
>>>> - It won't use Archetypes
>>>>
>>> I have one remark on this: that means LinguaPlone will no longer be
>>> supported. Unless there is an alternative that means an important use
>>> case will no longer be possible.
>>>
>>
>> I thought plone.app.multilingual would supercede LP and be more general,
>> but maybe that's stagnated?
>>
>
> It's been stalled for months. Ramon was side-tracked on getting
> plone.relations working in Plone 3. By the time that was resolved he was
> out of time and has not been able to continue working on multilingual.
That's a shame. :-/
>> This is also why I don't really think of this as a direct successor to
>> Archetypes. It's more an effort to think about new and better ways to
>> build content types, making this a task that's accessible to
>> administrators and power users, not just programmers. I don't really
>> want to be constrained by the current way AT works, at least not in the
>> initial design/thinking.
>>
>
> Sure, however we need to take into account that we should not end up in
> a situation where we will need two multilingual systems (LP for AT
> types, something else for dexteriy), two linkintegrity systems, two
> schema extension mechanism, etc. Telling people that if they want to
> extend an AT type they need to use solutions A but if they want to
> extend a dexterity type they will need to use solution B. We will be
> dealing with systems that use both AT and non-AT types for a few years
> so AT support is paramount.
Having two ways to do things would indeed suck. At least if they are
things that integrators and developers would be expected to have to do.
I'm not sure built-in Dexterity-creates-AT support is *necessarily* the
right answer, though it's definitely something we should investigate
properly.
I worry that we'll spend a lot of time fighting the framework if this is
AT based, since AT just wasn't designed for this kind of thing. I tried
to make AT use proper IFactory utilities in a backwards-compatible way
once, for example, and had to give up. Add forms is really tricky. The
reference engine implementation is slow and the API is a mess. I would
also *really* like for the in-memory/introspectable schema to be based
on something generic like zope.schema, not
Products.Archetypes.Schema.Schema.
If we *do* ever want to contemplate slowly migrating away from an
AT-centric view of content in Plone, then this is probably the right
place to do it, when we are trying to rethink some of the paradigms
around content types.
Here's my list of things that I think depend on AT right now, with some
notes about how tied in they really are:
- Inline validation (has largely transparent, non-AT equivalent in 3.1)
- Inline editing (has largely transparent, non-AT equivalent in 3.1)
- Reference engine (has non-AT, more sane equivalent in
plone.app.relations; a mostly-backwards-compatible refactoring of AT to
use plone.app.relations should be possible, but 100% compatibility may
be hard)
- Transforms (will be generalised into plone.transforms, should be
possible to have generalisable PortalTransform fascade)
- Version-on-edit (should work if we just add an event handler)
- Staging w/ iterate (will require a new adapter for the reference
between baseline and working copy, otherwise not AT specific)
- Link integrity (will require a new adapter to extract text, should
use plone.app.relations for keeping track of references rather than AT
references)
- Multiple fieldsets w/ standard fields ala ATCT (mostly done with
plone.fieldsets)
- Field injection/schema extender (will need a formlib-based equivalent)
- Multi-lingual support (will need plone.multilingual to pick up again)
- Custom fields and widget that have no AT equivalent (may be able to
bridge the gap here with Fate)
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See
http://martinaspeli.net/plone-book-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
