Re: [cowiki-dev] [cowiki] Using AJAX for form validation

For a purer sense of flexibility, we should allow bad wiki, in case 
there was no other way to express ones self. Otherwise we invite 
cumulative load-save errors-of-circumstance where a preview would have 
alerted all but the most illiterate user. For example, a table is left 
open, like so...

<table>
|-
| I'm behaving well but
| I'm going to forget to close this table

++ And on with the show...

...and how do we decide where to place the </table> closing element? At 
which point (during a parse) does the corrective code kick in? Do we 
walk the xml tree from the end to the beginning, looking-"ahead" for the 
best place to make an assumption?

Assumption is the mother of all fuckups; let's leave correction to 
eyeballing a preview - the customer is always right.

Regards,

Archie

PAUL HANCHETT wrote:

> I think I understand what you're saying Archie, but I don't know that 
> I agree.  There are quite a few elements that are required to be 
> paired, if they aren't the text won't be interpreted at all.  Now, I 
> suppose that we could add the missing elements to "correct" the markup...
>
> Archie Campbell wrote:
>
>> The thing with wiki markup is that the parser is required to accept 
>> just about anything, whereas syntax-checking requires the entire 
>> document to be grammatically defined. That is, the parser can't 
>> declare an error at such-and-such a place without expecting a given 
>> syntactic element at that place, which would restrict the set of 
>> parsable wiki documents to those having a set grammatic structure.
>>
>> Bottom line... it can't be done. If it could be done, it would cause 
>> all coWiki documents to be boring.
>>
>> Preview, on the other hand, would be fairly simple and wholly useful.
>>
>> Regards,
>>
>> Archie
>>
>> PAUL HANCHETT wrote:
>>
>>> Using AJAX to validate the page seems like a reasonable use, 
>>> especially if we can also use it to identify where the trouble spot 
>>> is.  I think it would be a good thing because then we wouldn't have 
>>> to save syntactically incorrect pages.
>>>
>>> I like the idea of offering a menu of valid links to insert.  Such a 
>>> thing could also be used to validate links once they are entered...
>>>
>>> Using it for page maintenance also seems to make sense...
>>>
>>> Should we think about including a WYSIWYG editor as well?  Clearly 
>>> it can be done...
>>>
>>> Daniel T. Gorski wrote:
>>>
>>>>On 18 Jun 14:06, John (yt) Hogenmiller wrote:
>>>>
>>>>  
>>>>
>>>>>On 6/18/05, Sy <[email protected]> wrote:
>>>>>    
>>>>>
>>>>
>>>>  
>>>>
>>>>>>At the very least, AJAX lets bandwidth usage be much more intelligent.
>>>>>>Sortof like what frames was supposed to do.  ;)
>>>>>>
>>>>>>      
>>>>>>
>>>>>Technically, AJAX (and methods like it) submit/retreive something
>>>>>every time you exit a  form element.  But it's a very small amount
>>>>>being submitted that typically, you barely notice.
>>>>>    
>>>>>
>>>>
>>>>At first I need to say that coWiki didn't require JavaScript so far. If you
>>>>want to change this basically, make it good. Means: if you want to use JS
>>>>someday and take it for granted for coWiki to work, you may replace some
>>>>functionalities with JS directly. These may be e.g. already existing
>>>>dialogues.
>>>>
>>>>Such (XML)-RPCs/requests like this AJAX (horrible name for an old
>>>>technology) provides, make sense in at least two coWiki cases:
>>>>
>>>> a) The display of the tree if you want to move documents. To select the
>>>>    target branch you may use XML-RPC to retrieve the subtree data to be
>>>>    displayed. This would also scale in the case that the tree has > 10.000
>>>>    nodes or such.
>>>>
>>>> b) If you have a smart textarea that displays an additionaly layer with
>>>>    document name suggestions after you typed "((" or "[[" and a few
>>>>    characters. I think I don't need to describe this functionality further.
>>>>
>>>>regards dtg
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [email protected]
>>>>For additional commands, e-mail: [email protected]
>>>>
>>>>  
>>>>