Nov 16, 2006, 5:51 AM
Post #2 of 3
(1049 views)
Permalink
Ferenc Szekely wrote:
>
> i think there are problems with the composite component. for instance
> adding several images as attachments work in the editor, but then in
> aegir those attachments are not editable anymore.
>
Said attachments are attached to the parent object if I remember
correctly, but why would you need to edit them in Aegir (see last
paragraph for MidCOM vs Aegir/Spider in general) ??
Technically the composite is not a component but a datatype (and
corresponding widget) in DataManager2, in any case since MidCOM defines
"component" very specificly maybe "functionality" would be a better word.
The problems of composites are not in the backend but some UI
limitations related either to how the AJAX editing (in general, many
other things use it as well) works or to certain widgets which are not
"automatically" AJAX editor compatible due to the way they work.
>
> or an other issue: removing an index page which has some images inside
> this composite stuff will not succeed within aegir. one has to go and
> remove the page from the mysql DB (article and article_i tables).
> i also failed to replicate a frontapge that has several images (approval
> was done of course).
>
*Never* delete anything from the database directly unless you *really*
know what you are doing (this requires deep understanding of how
libmidgard works), there is a lot of bookkeeping etc involved that
libmidgard does for you. The reason you could not immediately delete the
article in Aegir is that the composites are stored as "reply" articles
to the parent and must be removed first to maintain database consistency
(since they obviously depend on the parent being present), hence the
error "object has dependencies", in Aegir you can see the reply articles
but clicking on the + -icon next to the name of the article.
Replication is one of the things that absolutely depends on the
bookkeeping being done correctly (and now I will need to fix that
manually somehow, if you still have the IDs of the rows deleted
somewhere it will help), it simply cannot work without.
Also do remember that in 1.8 the "undelete" functionality exists even
though it's only for developer testing use (and thus its existence is
not advertised to the users), thus when object is deleted it's only
marked as such but not actually removed from database (for that a
separate purge method needs to be called). The legacy API always ignores
such objects and MgdSchema API by default ignores such objects but can
be requested to return them (and then the deleted flag can be cleared,
to undelete the object, or purge be called to remove it for good).
Unfortunately the current version of exorcist is still unaware of this
(and all other new in 1.8) metadata. jlz has been working on the 1.8
metadata format support for exorcist and it should be complete soon.
Thus deletions are not ATM replicated correctly.
In any case always use the MidCOM controls for managing the content, if
no control exists you can fall back on Spider/Aegir but avoid that if
you can, neither of them are in any way aware of the many things MidCOM
does behind the scenes and if we someday start to use components that
utilize the DBA watches then manipulating watched objects outside MidCOM
DBA API will simply be forbidden.
/Eero