[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #8895] REQ : Change to handling of Dynamic elements

From: Simon Stapleton
Subject: [bugs #8895] REQ : Change to handling of Dynamic elements
Date: Wed, 12 May 2004 04:34:22 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

[bugs #8895] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8895>
Project: GNUstep
Submitted by: Simon Stapleton
On: Wed 05/12/04 at 08:33

Category:  gsweb
Severity:  5 - Average
Item Group:  Change Request
Resolution:  None
Assigned to:  None
Status:  Open

Summary:  REQ : Change to handling of Dynamic elements

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.


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?

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]