[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