[ic] Problems with component cloning and creation

Gert van der Spoel ic at 3edge.com
Sun Sep 4 05:14:30 EDT 2005

> I've started to create my own components, but first tried to customize 
> some of the components already available in the dist. The problem is that 
> the function: 
> UI -> Content -> Component edit -> Existing components
> and on the Component Edit screen
> New name + click on Publish
> doesn't seem to work.

It looks to be not working. The issue appears to be that the behaviour of 
the Component Edit is 'modification of content', but putting a new name 
would change this to 'add new component'. The source does not seem to be 
prepared for that. 

I changed two files to sort this out in the admin UI backend:
*  lib/UI/ContentEditor.pm   (patch below, based on
$Id: ContentEditor.pm,v 2.14 2004/02/23 01:55:50 racke Exp $)
*  lib/UI/pages/admin/content_publish.html (patch below) 

Probably a bit of an ugly hack, but it appears to work. Basically after 
get_store determined that the 'old' component exists, the name of the old 
component is replaced with the new name. I have not tested it to large 
extend, but as far as I could see it is doing the trick. 

One thing to debate for this one would be that ui_source is still the 'old' 
component name. But that would be easy to add to this aswell. 

Of course the flow for the new name should not be through 'content_modify', 
but someting like 'new_component', but that is a bit too complex for a 
saturday evening :) 

> Beside this, when I try to create a new control and miss to specify the 
> value for Identifier I get a somewhat cryptic message: 
> content_modify: op add failed for component xxxxxx 
> It would be nice to have the actual dependency being stated, like: 
> Field xxxxx is mandatory. Please fill it out.

This is hardcoded in ContentEditor.pm:
if(! $sub->($ref, $opt) ) {
 pain('content_modify', "op %s failed for %s %s.", $op, $type, $name);

If the dependency would be added here I don't know if that would cause this 
to be showing at other points, not sure atm if this is being used for more 
than this particular place. If the dependencies are added, it would also be 
nice to have these text in a way that they can show translated aswell. 

If it is for a client to use the admin you could add some extra 
clarification to the 'Identifier' item, making it bold and adding a '*'. 
That would give the person creating the controls a basic idea already. 

You would do this is your mv_metadata.asc file afaik. 

> I have some trouble with "Lookup table" and "Lookup select", too. When I 
> fill out these two, the system automatically fills "Field for lookup" with 
> the value from "Lookup select" out, too. ???

This one I leave for the others 

 ----- Patches -----
 --- ContentEditor.pm.orig       2005-09-03 21:22:02.000000000 +0200
+++ ContentEditor.pm    2005-09-04 02:49:32.000000000 +0200
@@ -2708,6 +2708,12 @@
       my $ref = get_store($type,$name)
               or return death('content_modify', "%s %s not found", $type, 

+       #thunder_hack (tm) in case of an alternative component name
+       if ($vref->{ui_destination} ne "") {
+           $name = $ref->{ui_name} = $vref->{ui_destination};
+       }
       foreach my $op (@ops) {
#::logDebug("content_modify: doing name=$name type=$type op=$op");
#::logDebug("content_modify: doing name=$name type=$type op=$op ref=" . 


 --- content_publish.html.orig   2002-09-13 22:46:20.000000000 +0200
+++ content_publish.html        2005-09-04 02:12:09.000000000 +0200
@@ -52,7 +52,12 @@ 

[if cgi ui_content_op]
       [if type=explicit compare="[content-modify]"]
 -               [warnings message="Published [cgi ui_type] [cgi ui_name]."]
+               [if cgi ui_destination ne ""]
+                       [warnings message="Published [cgi ui_type] [cgi 
+               [else]
+                       [warnings message="Published [cgi ui_type] [cgi 
+               [/else]
+               [/if]
       [bounce page=__UI_BASE__/content]

More information about the interchange-users mailing list