bugGNUstep - Bugs: bug #8895, REQ : Change to handling of...

Group
 
 

bug #8895: REQ : Change to handling of Dynamic elements

Submitter:  Simon Stapleton <tufty>
Submitted:  Wed 12 May 2004 08:33:45 AM UTC
   
 
Category:  gsweb Severity:  3 - Normal
Item Group:  Change Request Status:  None
Privacy:  Public Assigned to:  mguesdon
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 09 Jun 2004 08:18:53 AM UTC, comment #3: 

(Sorry, the last comment took a while to get through to me due to mail issues...)

What I'm trying to produce here is xhtml-strict compliant sites.  While html (and xhtml-transitional, for that matter) tolerate unclosed tags, that doesn't mean we should be producing them ;-)  It's tolerated markup, but not, strictly speaking, correct.

Simon

Simon Stapleton <tufty>
Sat 15 May 2004 07:55:08 AM UTC, comment #2: 

Well, I have a need for some rather esoteric dynamic elements, much of which stems from the fact I'm working on xhtml sites that need to comply to accessibility rules.  In order to generate them, I need to get 'down and dirty' with the guts of GSWHTMLDynamicElement

One of these is a validated textfield.  The use I propose is as follows:

I generate a form filled with validated textfields, each of which has, among other things, a binding to an error dictionary
When the form is submitted, the validating code (typically the action of the submit button) populates an error dictionary, keyed on the names of the bound values being validated, containing the error string for that particular textfield.
We go back around the event loop, where we hit appendToResponse:inContext:.  In this, the textfields look in the error dictionary (which is bound, remember) for errors corresponding to themselves (where the key for 'themselves' is found by interrogating their own binding for 'value').  If they find one, they 'hilight' themselves (as I'm using xhtml, they set their 'class' attribute to be something defined in the css), and set their 'title' attribute to be the error string.  They then call the superclass appendToResponse:inContext: code to actually generate the tag. As you can see, I need to be able to dynamically change various bound attributes, or I end up having to reimplement all of GSWTextField's behaviour in my subclass

Typical bindings for an element like this would be:

SomeField : ValidatedTextField {
  /* normal TextField bindings apply */
  errorDictionary = errorDict;  // Bind my error dictionary
  errorAttribute = "class";  // In the event of an error, we set 'class'
  errorValue = "error";  // to 'error'
  class = "textfield"; // the 'normal' class
  title = "Enter some data here";  // The 'normal' title attribute
}

So, in 'normal' behaviour, the tage generated would be:

<input .... class="textfield" title="Enter some data here" />

but in the event of the error "Doofus! Enter some Data!" being set in the error dict for this field, we would get

<input ... class="error" title= "Doofus! Enter some Data!" />

I have a few components similar to this, and will be quite happy to donate them to the project once they're working properly.

Simon

Simon Stapleton <tufty>
Fri 14 May 2004 08:49:40 AM UTC, comment #1: 

I plan to rewrite DynamicElement next weeks.
But on you problem, I'm not sure to understand.
When you have something like:
<gsweb name="MyDynamicElement" anAttr="attrValue"></gsweb>
Do you want to set attrValue or get it ? Do you have a concrete example ?

Manuel

Manuel Guesdon <mguesdon>
Group Member
Wed 12 May 2004 08:33:45 AM UTC, original submission:  

I'm currently putting together a website that uses title attributes heavily (accessibility and all that), and as a result I'm putting together a lot of dynamic elements.

I would like, for example, to use the title attribute of an input field to indicate error status.  However, once I've created the element, I can't get to its attributes, which become part of the htmlBareStrings.  I could deal with the attribute locally, but then I have to redo appendToRequest:inContext:.  It seems to me that it would be nice to be able to 'get at' the bare strings in a more accessible way, and to mutate them during the lifetime of the element.  I've found that if I add an element to htmlBareStrings and then call parent appendToRequest:inContext:, the number of elements doesn't change, and I lose the end tag.

So.

I propose changes to GSWHTMLDynamicElement as follows:

First off, have an 'isStandalone' flag so we can make standalone tags generate the proper closing (See my other bug)

Next up, rip all the non-element attributes (i.e. those that would generate static attributes within the tag itself) into a dictionary, and redo the 'drawing' code to use this instead of the current static string that is built.

that way, I can override appendToResponse:inContext: to create a new attribute dictionary 'on the fly', temporarily replace the existing dictionary, call superclass drawing code, then replace the original dictionary.

Would this work?

Simon Stapleton <tufty>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-05-14 mguesdon Assigned toNone mguesdon
    Carbon-Copy- Added tufty

Back to the top

Powered by Savane 3.13-461b.
Corresponding source code