[Seaside] Seaside Portability Between Different Vendors?

[Mariano Martinez Peck]

The problem is not your seaside code but all the external libraries that you
use that may be different or even don't exist in other dialect. For example,
a database driver. Or if you talk to an external library. But yes, most of
the seaside code (your components) should me mostly portable if you pay
attention to the link provided by James.

On Tue, May 18, 2010 at 12:11 AM, James Foster <Smalltalk at jgfoster.net>wrote:

> Paul,
>
> http://code.google.com/p/seaside/wiki/CodingConventions contains a good
> list of ways of ensuring maximum portability. If you stick mostly to ANSI
> Smalltalk and don't use dialect-specific libraries, then even a complex
> application should be mostly portable.
>
> GemStone has a package to which Squeak/Pharo code is added to increase
> portability.
>
> James
>
> On May 17, 2010, at 2:24 PM, Paul B wrote:
>
> > If I wrote a moderately complex Seaside app.. let's say in Pharo.. could
> I move that app to Gemstone, or Cincom, or Dolphin etc. without making allot
> of changes?
> >
> > I was wondering if writing an app for one vendor image kind of locks you
> in to that image.
> >
> > What coding practices should one avoid if they want the option to change
> images in the future?
> >
> > (..so many good vendors out there ;)
> _______________________________________________
> > seaside mailing list
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100518/b485a14b/attachment-0001.htm