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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  Simon Stapleton <tufty>
Submitted on:  Wed 12 May 2004 08:33:45 AM UTC  
 
Category: gswebSeverity: 3 - Normal
Item Group: Change RequestStatus: None
Privacy: PublicAssigned to: Manuel Guesdon <mguesdon>
Open/Closed: Open

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>
Project MemberIn charge of this item.
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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 14 May 2004 08:49:40 AM UTCmguesdonAssigned toNone=>mguesdon
  Carbon-Copy-=>Added tufty

Back to the top


Powered by Savane 3.1-cleanup1