[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,
$name);
+ #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=" .
uneval($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
ui_destination]."]
+ [else]
+ [warnings message="Published [cgi ui_type] [cgi
ui_name]."]
+ [/else]
+ [/if]
[/if]
[bounce page=__UI_BASE__/content]
[/if]
More information about the interchange-users
mailing list