[Seaside] HTTP Post

Daniel Salama dsalama at user.net
Wed Jun 22 16:17:50 CEST 2005


Yanni/David/Avi,

Thanks for the responses. They have definitely helped me.

David, the external app will ONLY use the form POST to exchange data  
(this is from an old MS FoxPro application). Now, as far as only  
needing to interact with Seaside vs just using Comanche, that's a  
valid question. The only thing is that because I'm using this method  
to synchronize certain information from the FoxPro app, I need to use  
the model and business rules defined in the Seaside app. I can look  
into the possibility of using those rules from outside of Seaside and  
then just be able to use Comanche. I suppose that if the Seaside  
application is properly designed, I should be able to use Seaside  
mainly for the UI portion and keep my models and business logic  
external to it.

Thanks all,
Daniel

On Jun 22, 2005, at 8:03 AM, Avi Bryant wrote:

> On 6/22/05, David Shaffer <cdshaffer at acm.org> wrote:
>
>
>> Another thing to think about...does your external agent really  
>> need to
>> interact with Seaside, per se?  I find Comanche modules (basically
>> "Servlets") quicker to write for applications that _only_ deal with
>> automated agents.  The control flow is much more constrained than an
>> interactive app.  You can have the same Squeak/Comanche server  
>> serving
>> out Seaside and non-Seaside applications.  They can even share  
>> most of
>> their code.  There are examples of Comanche modules all over your  
>> image
>> (look for implementers of processHttp).  Learning to configure  
>> Comanche
>> and be a bit of a headache but once you've got it it seems quite  
>> simple
>> :-)  I can provide a more complex example that elaborates on this if
>> you're interested.
>>
>
> I used to do that too, but I've started doing subclasses of
> WAEntryPoint instead.  These can be extremely simple: just implement
> #handleRequest: which takes a WARequest and is expected to return a
> WAResponse.  If you implement #description on the class side, they'll
> show up in /seaside/config and you can assign them paths in the same
> namespace as your seaside apps (they'll show up in the same menu as
> Seaside Application).  That stops you from having to bother with
> Comanche config.  If you get ambitious, you can also override
> #configurationComponent...
>
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>



More information about the Seaside mailing list