Re: Code generation or forms?

On Jun 13, 2005, at 11:42 PM, Paul Downey wrote:


>>
>> A code-generation approach to that might reasonably assume that the
>> name values were fixed for the lifetime of the service and therefore
>> hard-code them.  But are they?
>>
>
> Er, fixed is a bit strong. The service will continue to accept these
> values as input for its lifetime, well yes, otherwise it's a non- 
> compatible
> change and will break existing clients, be they dynamic or code  
> generated.

Hmm...IMHO the whole point of using Web architecture for building  
networked applications is that existing clients do NOT break  
(neccessarily) in a case you describe above (e.g. by being provided  
with, or looking elsewhere for, code that allows them to handle the  
change.

That is why I think there is not much sense in generating client-side  
code; it is just an unneccessary form of coupling and constradicts  
what Web architecture intends to acomplish.

>
>> In a forms based approach, they need not
>> be, and the agent may instead rely on other information such as a
>> "type", or data available from an associated URI (as RDF Forms does,
>> though I'm not sure that's best).  While this can be remedied by just
>> specifying that names may change, I think it, and the other example
>> above, demonstrate that there is a line here that we need to keep in
>> mind and IMO, avoid crossing.
>>
>
> I think incompatible changes are going to cause problems regardless
> of if the code is generated or more dynamic agent is involved. All
> being dynamic does is to typically shorten the window between getting
> the description and sending the data:
>
> I go to buy a book from Amazon, fill in their form, but then realise
> i left my credit card at the office. An hour later, back from work
> I complete the form. If in the meantime Amazon change the service
> in an incompatible way, my request will fail.

Incompatible with WHAT????

Since your browser only relies on the semantics of the HTML MIME type  
(for the
Amazon purchase case) the contrary is true: Amazon *can* change the  
service and
you can still complete your tour through the Web app's state machine.

Hmm interesting feature (if I have this correctly): A Web application  
can in fact
change it's state machine while it is executed by clients.

Jan


>
>
>> Got any code generation use cases for me now? 8-)
>>
>
> yeah, I actually wrote this Email using Perl print statements.
> Can't you tell :-)
>
>
>> --
>>
> http://blog.whatfettle.com
>
>
>

________________________________________________________________________ 
____________________
Jan Algermissen, Consultant & Programmer                              
http://jalgermissen.com
Tugboat Consulting, 'Applying Web technology to enterprise IT'        
http://www.tugboat.de

Received on Monday, 13 June 2005 22:16:37 UTC