DM2 Schema Integration
-
Andreas Flack
DM2 Schema Integration
Fri April 11 2008 11:25:03 UTCHi!
I'm in the process of unleashing a 2.8 based CMS site on a client for
the first time. So far, the "real life" feedback is ok, except for a few
known bugs (like #224).
One sore point stands out, however: I used DM2 schemas to allow for
different kinds of articles in some topics, which save a few additional
fields in parameters. On the admin site, creating those schemas is
pretty easy and works as expected, but with the big gotcha that a typo
in the n.n.static default schema db (assuming that your root topic is
n.n.static) will inevitably and irreversibly make both Asgard and the
site inaccessible. The only remedy right now is to open sper-admin,
aegir or phpmyadmin and to correct the error there. So either some form
of input validation or better yet, a dedicated schema editor would be a
real help here.
But the main problem is that Asgard doesn't seem to support component
schemas at all right now. If I have a schema looking like this:
'infobox' => array
(
'description' => 'Info Box',
'fields' => array
(
'name' => Array
(
// COMPONENT-REQUIRED
'title' => 'url name',
'storage' => 'name',
'type' => 'text',
'widget' => 'text',
'write_privilege' => array
(
'privilege' => 'midcom:urlname',
),
),
'title' => Array
(
// COMPONENT-REQUIRED
'title' => 'title',
'storage' => 'title',
'required' => true,
'type' => 'text',
'widget' => 'text',
),
'abstract' => Array
(
// COMPONENT-REQUIRED
'title' => 'abstract',
'storage' => 'abstract',
'type' => 'text',
'widget' => 'textarea',
),
'content' => Array
(
// COMPONENT-REQUIRED
'title' => 'content',
'storage' => 'content',
'hidden' => true,
'type' => 'text',
'widget' => 'textarea',
),
'link' => Array
(
// COMPONENT-REQUIRED
'title' => 'Link',
'storage' => 'parameter',
'required' => true,
'type' => 'text',
'widget' => 'text',
),
),
),
I.e. one of the standard fields is hidden, another field is added with
parameter storage location, the following happens:
1: User creates an "infobox" schema-based article on-site: Everything
works as expected
2: User later visits Asgard to edit the article: The autogenerated
article form is displayed, i.e. the 'link' field is missing (or to be
exact: it is hidden in the "Parameters" tab), and the hidden content
field is displayed.
Which of course means that even in this simple case, editing in Asgard
is not possible in a straightforward way. If the parameter field would
have a select widget, you couldn't even tell the users to edit this
field under parameters, because you don't know what the correct values
are supposed to be.
From user feedback, it also seems that its a big problem that the
different DM2 schema types are visually identical, i.e. if you have
articles of three different DM2 schema types in the same topic, in
Asgard's tree view and in the toolbar's sort function, they all use the
same icon, which is really confusing for users.
The remedy for the second problem is of course very simple. It would be
enough to add an 'icon' field to the DM2 schema definition (similar to
what is already possible in DBA classes and component manifests), and I
would propose to do just that.
However, I'm not so sure what to do about the first issue: The current
behaviour had the advantage that it gives you a sort of "unfiltered"
view of the DB objects, but it has the big disadvantage that it makes
Asgard almost unusable for normal content editors (unless of course
there is some hidden checkbox or variable that makes Asgard schema
aware. If yes, pls let me know).
The reason for using Asgard for content editing in the first place were
that certain articles are only shown in list views on-site, so the are
inaccessible for editing from the toolbar. In Asgard, you have the full
tree view and can therefor access all existing elements.
So my ideas would be to either create a dedicated "content editor"
plugin in Asgard, which would combine the Asgard nav tree (and edit
possibly the Asgard toolbar) with the DM2 schemas used onsite. The other
alternative could be provide some sort of floating (NAP?) tree navigator
on-site that allows you to access all children of the current topic.
So I wanted to ask if there are already plans for DM2 schema integration
in Asgard and if yes what they look like. Did anyone have similar
problems or would you rather say that mixing different DM2 schemas in
one Topic is discouraged and that DM2 schemas are unsupported in Asgard?
Bye,
Andreas
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: DM2 Schema Integration
Sat April 12 2008 16:13:18 UTCThe reason for using Asgard for content editing in the first place were that certain articles are only shown in list views on-site, so the are inaccessible for editing from the toolbar. In Asgard, you have the full tree view and can therefor access all existing elements.
Add to your styles an edit link behind
if ($object->can_do('midgard:update')), I cannot think of single default component setup where something was not accessible so that one could edit it (unless specifically by design: like in forum where editing of posts is disallowed).So my ideas would be to either create a dedicated "content editor" plugin in Asgard, which would combine the Asgard nav tree (and edit possibly the Asgard toolbar) with the DM2 schemas used onsite.
This is what the components are for, they know all the context etc.
Asgard is (almost) purely reflection based heuristics (some people added some component/class specific exceptions while I wasn't looking, I frown upon them...) and that's exactly the way it should stay, it's meant for low-level access to all of the loaded MgdSchemas not as replacement for component object management interfaces.
I guess this is a clash of culture but the fact is that Asgard is not meant for end-users (that's why it has specific privilege for even accessing it).
AIS (remember midcom up to 2.4) was sorta-kinda what you seem to want but we walked away from that for a bunch of reasons.
I don't think schema typo can anymore break Asgard and in Asgard if a property is determined to be 'code' (like page or snippet content) then it's validated with
php -l(DM2 php datatype feature).There has been talk about a dedicated schema editor for years. The problem is that to cover even 80% of the things you can do with DM2 is a ton of work. So far no-one has been interested in paying the price (be it free their time and skills or money either by paying someone else to do it or working on it pro-bono).
/Rambo
-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Sat April 12 2008 18:10:03 UTCEero af Heurlin schrieb:
>> The reason for using Asgard for content editing in the first place were
> that certain articles are only shown in list views on-site, so the are
> inaccessible for editing from the toolbar. In Asgard, you have the full
> tree view and can therefor access all existing elements.
>
> Add to your styles an edit link behind `if ($object->can_do('midgard:update'))`, I cannot think of single default component setup where something was not accessible so that one could edit it (unless specifically by design: like in forum where editing of posts is disallowed).
>
Yes, this is what I ended up doing, but I would rather consider this a
workaround than a proper solution (F.x. this has the side effect that
anyone with editing rights needs a second account to see how the site
looks to normal users).
Also, it is still easy to make content inaccessible to editors: F.x.
Disable archive access in n.n.blog and create more then 20 articles. The
oldest ones are still accessible via the search function, Asgard or by
entering the URL directly, but not though the toolbar.
>> So my ideas would be to either create a dedicated "content editor"
> plugin in Asgard, which would combine the Asgard nav tree (and edit
> possibly the Asgard toolbar) with the DM2 schemas used onsite.
>
> This is what the components are for, they know all the context etc.
Yes, they do. But usually their layout is geared towards end users, i.e.
site viewers, not site editors. Of course you can try to implement
something that works tolerably well for both modes, but you'll always
end up making compromises.
>
> Asgard is (almost) purely reflection based heuristics (some people added some component/class specific exceptions while I wasn't looking, I frown upon them...) and that's exactly the way it should stay, it's meant for low-level access to all of the loaded MgdSchemas not as replacement for component object management interfaces.
>
> I guess this is a clash of culture but the fact is that Asgard is not meant for end-users (that's why it has specific privilege for even accessing it).
>
OK, so if Asgard is meant to be sort of a phpMyAdmin optimized for
Midgard DBs and the toolbar's usefulness is limited by its nature (as
it's just not possible to cram every feature one might need into one of
the three submenus), then the position of the content editor admin
interface is still vacant.
Basically I agree that there should be a low-level interface like
Asgard, but most CMSs also provide a high-level interface (or a
two-tiered system) for editors. I mean, I like the onsite editing
facilities and all, but if you're doing more than a few casual edits
(like f.x. the relaunch of an entire site), it just doesn't scale so
well and less experienced users tend to lose orientation with it very fast:
If you don't really grasp the distinction between topics and articles
and are not familiar with deducing the structure of the content tree and
your current position in it from the browser's location bar, you usually
don't have a clue why sometimes you have to choose from the folder menu
and sometimes from the article menu to achieve seemingly similar goals.
And now that the .html suffixes are gradually removed, I can't even say
to people that they can tell where they are right now by looking at the
end of the URL ("/" for topics and ".html" for articles was a real
no-brainer).
Since most people are familiar with the folder/file metaphor, actually
displaying content in a folder tree representation makes it more
intuitive for them. Case in point: Even in 2.6 sites I found that
editors regularily preferred Aegir in its unmaintained, crippled form to
using the toolbar, simply because they felt completely lost with it.
> AIS (remember midcom up to 2.4) was sorta-kinda what you seem to want but we walked away from that for a bunch of reasons.
>
Well, it was pretty crappy anyways, so I don't think anybody lost much
sleep over its demise. Also, what I'm looking for would rather be a
successor to Aegir, not because I personally liked it so much (I always
preferred Spider-Admin), but because it seems to work for content editors.
> I don't think schema typo can anymore break Asgard and in Asgard if a property is determined to be 'code' (like page or snippet content) then it's validated with `php -l` (DM2 php datatype feature).
>
The validation of the 'code' type is indeed very helpful, but it only
kicks in when an opening <?php tag is found, so for schemas which only
contain arrays, you're out of luck, since from the point of view of the
validator, they look like regular plaintext. You can easily try this by
creating a n.n.static root topic, then a schema database for it in
sitegroup-config. Remove one comma or quotation mark, save it, and watch
the 500 errors onsite and in every page in Asgard.
> There has been talk about a dedicated schema editor for years. The problem is that to cover even 80% of the things you can do with DM2 is a ton of work. So far no-one has been interested in paying the price (be it free their time and skills or money either by paying someone else to do it or working on it pro-bono).
>
Yeah, I can imagine that this is one big headache. But you have to admit
that this could really boost MidCOM's standing in the "market", so to
speak. Finding a CMS plugin that represents the data structure you need
well is something that always comes up when people are trying to setup
sites with systems like drupal or typo3. If you could tell them: Well,
in MidCOM, you can just adapt the component's data structure AND you
don't have to mess with gigantic and incredibly fragile config files,
that would certainly stir up some interest.
Bye,
Andreas
> /Rambo
> _______________________________________________
> dev mailing list
> dev@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Sun April 13 2008 11:25:03 UTC-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
<(snip)>
>>> So my ideas would be to either create a dedicated "content editor"
>> plugin in Asgard, which would combine the Asgard nav tree (and edit
>> possibly the Asgard toolbar) with the DM2 schemas used onsite.
>> This is what the components are for, they know all the context etc.
>
> Yes, they do. But usually their layout is geared towards end users, i.e.
> site viewers, not site editors. Of course you can try to implement
> something that works tolerably well for both modes, but you'll always
> end up making compromises.
One thing that is a posibility and probably not very hard, is to use frames:
Create a component showing what you want in a tree like structure on one
side with links into the real pages on the other side. This should not
be too hard to do and would give you 90% of what you want.
>> I don't think schema typo can anymore break Asgard and in Asgard if a
>> property is determined to be 'code' (like page or snippet content)
>> then it's validated with `php -l` (DM2 php datatype feature).
>>
What we need is a way to configure asgard only sites -> i.e. that you do
not have to be dependent on the normal MidCOM startup to get to the site.
> The validation of the 'code' type is indeed very helpful, but it only
> kicks in when an opening <?php tag is found, so for schemas which only
> contain arrays, you're out of luck, since from the point of view of the
> validator, they look like regular plaintext. You can easily try this by
> creating a n.n.static root topic, then a schema database for it in
> sitegroup-config. Remove one comma or quotation mark, save it, and watch
> the 500 errors onsite and in every page in Asgard.
Schemas shouldn't be in code anyhow. We should move to using either YAML
(preferabley) or XML and using the code just for caching.
This is also needed if we are ever to get to the point where we can edit
the code.
Regards,
Tarjei
>
>> There has been talk about a dedicated schema editor for years. The
>> problem is that to cover even 80% of the things you can do with DM2
>> is a ton of work. So far no-one has been interested in paying the
>> price (be it free their time and skills or money either by paying
>> someone else to do it or working on it pro-bono).
>>
>
> Yeah, I can imagine that this is one big headache. But you have to admit
> that this could really boost MidCOM's standing in the "market", so to
> speak. Finding a CMS plugin that represents the data structure you need
> well is something that always comes up when people are trying to setup
> sites with systems like drupal or typo3. If you could tell them: Well,
> in MidCOM, you can just adapt the component's data structure AND you
> don't have to mess with gigantic and incredibly fragile config files,
> that would certainly stir up some interest.
>
>
> Bye,
>
> Andreas
>
>
>> /Rambo
>> _______________________________________________
>> dev mailing list
>> dev@lists.midgard-project.org
>> http://lists.midgard-project.org/mailman/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIAc7EYVRKCnSvzfIRAmnTAJwPKUKrScUQOI3JiGO4798BbgvyqgCgjHfr
vRPcmsTTthTlnjHMxSXTb6Q=
=mqQ9
-----END PGP SIGNATURE-----
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Sun April 13 2008 17:45:03 UTCHi,
On Sun, Apr 13, 2008 at 12:13 PM, tarjei <tarjei@nu.no> wrote:
> Schemas shouldn't be in code anyhow. We should move to using either YAML
> (preferabley) or XML and using the code just for caching.
In MidCOM3 datamanager we're using YAML for DM schemas. But I wouldn't
go changing this for MidCOM 2.x
> Tarjei
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Sun April 13 2008 17:50:02 UTCHi,
On Sat, Apr 12, 2008 at 9:07 PM, Andreas Flack
<flack@contentcontrol-berlin.de> wrote:
> Yeah, I can imagine that this is one big headache. But you have to admit
> that this could really boost MidCOM's standing in the "market", so to speak.
> Finding a CMS plugin that represents the data structure you need well is
> something that always comes up when people are trying to setup sites with
> systems like drupal or typo3. If you could tell them: Well, in MidCOM, you
> can just adapt the component's data structure AND you don't have to mess
> with gigantic and incredibly fragile config files, that would certainly stir
> up some interest.
I fully agree. We should focus on making this customization (both
schema and style) as easy as possible, and with a full UI in MidCOM 3.
Related to that, I'm prepared to put in some funding for a nice schema
editor (MidCOM 2.x or 3).
> Andreas
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Mon April 14 2008 06:23:44 UTCRelated to that, I'm prepared to put in some funding for a nice schema editor (MidCOM 2.x or 3).
Considering MidCOM 3 DM is very similar in design to DM2 and currently the schemas are compatible (just the representation, YAML vs array(), is different) with only minor considerations that would be good design in any case such editor could be used with both.
Apart from the headaches of the editor itself we just need to have some way for the datatypes and widgets to tell the editor what their configuration options are and what they mean.
In MidCOM3 it's possible to specify a full class name for widget/datatype (in stead of just 'text' you can put 'tld_mysite_widgets_mytext'), and obviously the editor really cannot be aware of all the widgets that might be usable outside the DM distribution version.
What we need is a way to configure asgard only sites -> i.e. that you do not have to be dependent on the normal MidCOM startup to get to the site.
We have been thinking about this, the simplest way is to use for example the default sitewizard as the entry point. Of course truly independent asgard would be better but it might be difficult in 2.x.
/Rambo
-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Mon April 14 2008 06:45:03 UTCHi,
On Mon, Apr 14, 2008 at 9:23 AM, Eero af Heurlin <rambo@nemein.com> wrote:
> Apart from the headaches of the editor itself we just need to have some way for the datatypes and widgets to tell the editor what their
> configuration options are and what they mean.
Widgets and types could have a "get_configuration_schema" method that
would return a DM schema for editing their config options.
> In MidCOM3 it's possible to specify a full class name for widget/datatype (in stead of just 'text' you can put 'tld_mysite_widgets_mytext'),
> and obviously the editor really cannot be aware of all the widgets that might be usable outside the DM distribution version.
Except if we "register" external types and widgets in manifests of
components shipping them.
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Mon April 14 2008 09:20:03 UTCHenri Bergius schrieb:
> Hi,
>
> On Sun, Apr 13, 2008 at 12:13 PM, tarjei <tarjei@nu.no> wrote:
>> Schemas shouldn't be in code anyhow. We should move to using either YAML
>> (preferabley) or XML and using the code just for caching.
>
> In MidCOM3 datamanager we're using YAML for DM schemas. But I wouldn't
> go changing this for MidCOM 2.x
Hi!
I have to admit that I don't knw anything about YAML, but I'm wondering
what will happen to constructs like
'hidden' => (!$_MIDCOM->auth->admin)
or
'options' => $GLOBALS['some_array']
Will this be supported in the future or is it considered bad form?
Bye,
Andreas
>
>> Tarjei
>
> /Henri
>
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-
-
Re: [midgard-dev] Re: DM2 Schema Integration
Mon April 14 2008 09:30:02 UTCtarjei schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> <(snip)>
>>>> So my ideas would be to either create a dedicated "content editor"
>>> plugin in Asgard, which would combine the Asgard nav tree (and edit
>>> possibly the Asgard toolbar) with the DM2 schemas used onsite.
>>> This is what the components are for, they know all the context etc.
>> Yes, they do. But usually their layout is geared towards end users, i.e.
>> site viewers, not site editors. Of course you can try to implement
>> something that works tolerably well for both modes, but you'll always
>> end up making compromises.
>
> One thing that is a posibility and probably not very hard, is to use frames:
> Create a component showing what you want in a tree like structure on one
> side with links into the real pages on the other side. This should not
> be too hard to do and would give you 90% of what you want.
>
Yes, I have been thinking about this, too, but I can't think of a way to
keep the frames properly synchronized. F.x. if you create a new article
or photo or rename an existing one, the tree in the navigation frame
should be updated accordingly. If you use a NAP tree and reload it every
time the main frame is reloaded, this would be doable, but the NAP tree
is not necessarily complete, f.x. in the view handler of n.n.blog (IIRC)
it is empty except for the link to the folder. And if you're using some
variant of the Asgard tree, figuring out which object is currently
displayed (and which subtrees to open) can be a challenge.
Bye,
Andreas
>>> I don't think schema typo can anymore break Asgard and in Asgard if a
>>> property is determined to be 'code' (like page or snippet content)
>>> then it's validated with `php -l` (DM2 php datatype feature).
>>>
> What we need is a way to configure asgard only sites -> i.e. that you do
> not have to be dependent on the normal MidCOM startup to get to the site.
>
>
>> The validation of the 'code' type is indeed very helpful, but it only
>> kicks in when an opening <?php tag is found, so for schemas which only
>> contain arrays, you're out of luck, since from the point of view of the
>> validator, they look like regular plaintext. You can easily try this by
>> creating a n.n.static root topic, then a schema database for it in
>> sitegroup-config. Remove one comma or quotation mark, save it, and watch
>> the 500 errors onsite and in every page in Asgard.
>
> Schemas shouldn't be in code anyhow. We should move to using either YAML
> (preferabley) or XML and using the code just for caching.
>
> This is also needed if we are ever to get to the point where we can edit
> the code.
>
>
> Regards,
> Tarjei
>>> There has been talk about a dedicated schema editor for years. The
>>> problem is that to cover even 80% of the things you can do with DM2
>>> is a ton of work. So far no-one has been interested in paying the
>>> price (be it free their time and skills or money either by paying
>>> someone else to do it or working on it pro-bono).
>>>
>> Yeah, I can imagine that this is one big headache. But you have to admit
>> that this could really boost MidCOM's standing in the "market", so to
>> speak. Finding a CMS plugin that represents the data structure you need
>> well is something that always comes up when people are trying to setup
>> sites with systems like drupal or typo3. If you could tell them: Well,
>> in MidCOM, you can just adapt the component's data structure AND you
>> don't have to mess with gigantic and incredibly fragile config files,
>> that would certainly stir up some interest.
>>
>>
>> Bye,
>>
>> Andreas
>>
>>
>>> /Rambo
>>> _______________________________________________
>>> dev mailing list
>>> dev@lists.midgard-project.org
>>> http://lists.midgard-project.org/mailman/listinfo/dev
>> _______________________________________________
>> dev mailing list
>> dev@lists.midgard-project.org
>> http://lists.midgard-project.org/mailman/listinfo/dev
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIAc7EYVRKCnSvzfIRAmnTAJwPKUKrScUQOI3JiGO4798BbgvyqgCgjHfr
> vRPcmsTTthTlnjHMxSXTb6Q=
> =mqQ9
> -----END PGP SIGNATURE-----
> _______________________________________________
> dev mailing list
> dev@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev-
Reply
-
Report abuse
-