[OGo-Developer] OWFormElementName

[Stéphane Corthésy]

Hi,

On Dec 12, 2006, at 20:43, Helge Hess wrote:

> On Dec 12, 2006, at 18:42, Stéphane Corthésy wrote:
>> I dug that problem deeper.
>> The error, committed in v1101, is in WOWrapperTemplateBuilder.m.  
>> In -dynamicElementWithName:attributes:contentElements:, there is a  =

>> call [self addAttributes:_attributes toAssociations:assoc].  
>> _attributes contains the element's 'name' (or 'NAME') that is in  
>> the <WEBOBJECT NAME=...> element,
>
> Yes.
>
>> and that name is added to the associations, whereas it shouldn't.
>
> No, it isn't, at least I can't see where and I can't reproduce your  =

> issue either.
> ---snip---
>   if (count == 1 && [_attrs objectForKey:@"NAME"] != nil)
>     return;
>
>   e = [_attrs keyEnumerator];
>   while ((key = [e nextObject]) != nil) {
>     BOOL doRelease;
>     id value;
>
>     if ([key isEqualToString:@"NAME"]) /* <WEBOBJECT NAME="">, not  =

> in assocs */
>       continue;
> ---snap---
> The 'NAME' is explicitly skipped.


OK for 'NAME', but not for 'name'... Template can contain <WEBOBJECT  
NAME=...> or <webobject name=...> (BTW, why does the WO parser checks  
only for WEBOBJECT/webobject and NAME/name? Tags should be case- 
insensitive); latest WOBuilder always uses lowercase tags.


>> By commenting that line out, problem is solved. If there could be  
>> more key-value pairs than the 'name' one (why/how? Not in a .wo  
>> template
>
> In SOPE you can override associations inside the template or even  
> have an element without a .wod entry, eg:
>   <#WOString var:value="customer.name" />
> or
>   <#MyString value="Title 1"/>
>   <#MyString value="Title 2"/>
>   <WEBOBJECT NAME="MyString" value="Title 3"></WEBOBJECT>
> with
>   MyString: WORichString {
>     bold = YES;
>   }
> etc.


OK, I understand that, but there is a flaw with the 'name' attribute:  
that attribute is (currently) both the attribute used internally by  
WO, AND the public attribute in the resulting HTML; that's where is  
the mistake. You'd better use the 'id' attribute, instead of the  
'name' one for javascript use.


>> , AFAIK, but probably in .wox ones)
>
> No, the .wox parser never populates the attrs, it directly builds  
> associations from the tag attributes.
>
>> , then we should simply remove those (name/NAME) ones from the  
>> dictionary passed to addAttributes:toAssociations:.
>
> Or skip them ;-)


I remove them after adding all attributes; it's simply 2 more lines  
after that call.


>> Though it is annoying to have to add an explicit 'name' attribute  
>> to WOElements when you need to refer to that element in  
>> javascript, for example, it is definitely not possible to use the
>> <WEBOBJECT NAME=...> value; you will have invalid HTML as soon as  =

>> your <WEBOBJECT NAME=...> is used more than once in your page, for  =

>> example wrapped in a WORepetition, or coming from another component.
>
> I absolutely agree. The 'WEBOBJECT NAME' shouldn't and has nothing  
> to do with the output.


OK, fine. So, let's fix that bug.


> Sorry, but as mentioned I can't reproduce your issue and in the  
> code it looks quite right?! :-(


Create a page containing this:

<webobject name="MyTextField1"></webobject>

MyTextField1: WOTextField {
	value = value;
}

You'll notice that the generated HTML contains the attribute  
name="MyTextField1".

Stéphane


> Greets,
>   Helge
> -- 
> Helge Hess
> http://docs.opengroupware.org/Members/helge/
>
>
> --
> OpenGroupware.org Developer
> developer@opengroupware.org
> http://mail.opengroupware.org/mailman/listinfo/developer