[
Lists Home |
Date Index |
Thread Index
]
Aleksander Slominski wrote:
> Mitch Amiano wrote:
>
>> At what point does creating entirely new systems using the most
>> antiquated technology become a gratuitous exercise?
>
>
> hi,
>
> maybe because it works? and works very well meeting all our needs?
(screaching halt to communication)
Ok, sorry, I obviously set the wrong tone with my post. I meant to ask rhetorically,
when do you determine that taking a pure HTML approach works so well that you
are willing to avoid new technology?
>> I don't mean to slur the posters, as I've had to use a technique
>> similiar to the one described a few years ago. But this seems to be
>> the case of painting one's self into a corner, or throwing good money
>> after poor practice.
>
>
> it is proof of concept and we are willing to explore alternatives (that
> is why i have posted it). what do you exactly propose?
If I accept the premise, that is, that your goal is to be a pure HTML implementation,
(disregarding my rhetoric above), then your design is quite reasonable.
Another variation on the naming convention is to use concatenated ID values, where the id of a child consists of the id of it's parent + a sequential number to indicate its ordinal position. E.g.
P-0
P-0.I-0
P-0.I-0.JI-0
P-0.I-0.JI-0.X1-0
These are valid identifiers, and can be ripped apart without knowing anything about XPath, to get at a specific element or any of its ancestors. However, I think perhaps you are looking for a location into an XML instance, and not a name?
>> The forward slash isn't a valid name character.
> we support both slash and escaped characters: initially we had / as %XX
> however it did not look nice and after checking with HTML browsers it
> looks like slash will work. if we had it deployed to more HTML clients
> we would generate appropriate filed name depending on browser name.
In the case of a forgiving html browser that strategy might work. I presume you aren't concerned that
foo/bar and foo%XXbar would be rejected by a software that expects valid names.
>> One could maintain a second, hidden form field which contains a simple
>> lookup table of html field names to XPath targets, as in
>> field1, param:parameters/input/job-input/x1/
>
>
> this does nor sound simple at all and does not scale for deeply nested
> XML instances: HTML field names are no longer self describing and even
> more: it has layer of indirection that prevents "View Source" editing of
> HTML ...
> it is my impression that doing View HTML source and than modifying was
> crucial to success of HTML and Web and as we wanted to make really easy
> to customize HTML forms we wanted to make it easy both to edit by hand
> (or text editor) and using more fancy visual editors - both approaches
> work now fine with HTML code that we generate and that can be used as
> template for better looking HTML page.
If viewing source and modifying it is important, then a level of indirection is not so good. But why not then simply provide the unmodified XML, or use a Wiki approach?
How does embedding a stripped down path expressing as a field name get better scalability for deeply nested XML? I mean, the path you use seems to be predicated upon generic element names, whereas your fields supposedly point to specific element instances.
>> The form is then self-describing, without violating any naming rules.
>> Of course, you still have a problem if you need to have multiple
>> elements as siblings, and need to specify the order, but you can solve
>> that with even more mangling to include parent/child pointers.
>
>
> exactly. this problem and wanting to avoid indirections coded in hidden
> fields ...
>
Good luck!
> thanks for your comments,
>
> alek
>
>> Aleksander Slominski wrote:
>>
>>>
>>> hi,
>>>
>>> another possibility is to reconstruct XML instance based on HTML form
>>> field names. it is straightforward and in case of nested XML elements
>>> they can be described by giving filed names that are hierarchical
>>> i.e. simplified XPATH such as <input
>>> name="param:parameters/input/job-input/x1/"type="text"value="" /> -
>>> such form field names are pretty much self describing :-).
>>>
>>> the main advantage is that such HTML form does not require
>>> javascript, DHTML, ... - but it is straight HTML form and can be
>>> displayed and processed on pretty much any HTML browser (we generate
>>> XHTML to simplify parsing but generated XHTML is 1.0 without any
>>> special features).
>>>
>>> for example of how such HTML form may look please see GAPP-WRF at
>>> http://linbox1.extreme.indiana.edu:8356/xwsfg
>>>
>>> thanks,
>>>
>>> alek
>>>
>>> Betty Harvey wrote:
>>>
>>>> John:
>>>>
>>>> About 4 years ago, I did an example of what you want to do.
>>>> The example is available at http://www.eccnet.com/xmledi. I think
>>>> you might it useful.
>>>>
>>>> Betty
>>>>
>>>> On Sat, 17 May 2003, John Stubbe wrote:
>>>>
>>>>
>>>>
>>>>> Hi
>>>>> I am stuck with a Form parsing problem.
>>>>> I am building a dynamic form creator system, and my problem is that
>>>>> I would like to send the whole structure of the form to a server as
>>>>> XML.
>>>>> Is this possible? I have tried to make a small example below. Does
>>>>> anybody know how I can do this?
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>> Best regards
>>>>>
>>>>> John
>>>>>
>>>>> <form action="#">
>>>>> <input type="text" value="someValue" />
>>>>> <br />
>>>>> <select>
>>>>> <option>value1</option>
>>>>> <option>value2</option>
>>>>> <option>value3</option>
>>>>> </select>
>>>>> <br />
>>>>> <textarea>Some text form a text area</textarea>
>>>>> <br />
>>>>> Check1: <input type="checkbox" name="check1" value="1">
>>>>> Check2:<input type="checkbox" name="check1" value="2" checked>
>>>>> Check3:<input type="checkbox" name="check1" value="3">
>>>>> <br />
>>>>> radio1<input type="radio" name="radio1" value="1">
>>>>> radio2<input type="radio" name="radio1" value="2">
>>>>> radio3<input type="radio" name="radio1" value="3">
>>>>> <br />
>>>>> <input type="Submit" value="submit" onclick="alert('submit XML')" />
>>>>> </form>
>>>>>
>>>>> I would like to recive someting like this:
>>>>>
>>>>> <?xml verson="1.0" ?>
>>>>> <form>
>>>>> <text>someValue</text>
>>>>> <select>
>>>>> <option>value1</option>
>>>>> <option selected="true">value1</option>
>>>>> <option>value2</option>
>>>>> </select>
>>>>> <checkbox name="check1">
>>>>> <check value="1">Check1</check>
>>>>> <check id="2">Check2</check>
>>>>> <check id="3">Check3</check>
>>>>> </checkbox>
>>>>> <radiobuttons>
>>>>> <input value="1">radio1</input>
>>>>> <input value="2">radio2</input>
>>>>> <input value="3">radio3</input>
>>>>> </radiobuttons>
>>>>> </form>
>>>>>
>>>>> _________________________________________________________________
>>>>> Nem, sjov og hurtig chat med vennerne med MSN Messenger
>>>>> http://messenger.msn.dk
>>>>>
>>>>>
>>>>> -----------------------------------------------------------------
>>>>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>>>>> initiative of OASIS <http://www.oasis-open.org>
>>>>>
>>>>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>>>>
>>>>> To subscribe or unsubscribe from this list use the subscription
>>>>> manager: <http://lists.xml.org/ob/adm.pl>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this list use the subscription
>> manager: <http://lists.xml.org/ob/adm.pl>
>>
>
>
|
