Dolphin for complete Business Apps for small / medium enterprises ?

This is an honest question / no flame wars etc

Considering all factors for a developer shop -
Is Dolphin good enough for developing complete integrated
business apps for small & medium scale organisations
I mean compared to other more macho Smalltalk's

1. Total appx 200-300 data entry screens & reports
2. 2-3 developers working
3. Mostly data-in / data-out functions against almost
      all known RDBMSs
4. Several different apps with same style / features
5. Ok... purely win enviroment (sacrificed)

What are we loosing (just to be prepared)

Regards
Sanjay Minni
www.minisoftindia.com


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/04

Sanjay,

> This is an honest question / no flame wars etc

Sounds good to us.


> Considering all factors for a developer shop -
> Is Dolphin good enough for developing complete integrated
> business apps for small & medium scale organisations
> I mean compared to other more macho Smalltalk's

That means VW and VA??  I have some VW experience, but not recently, and
I watched VA run one time - that's about it.  I make extensive use of
Dolphin, and consider it about as macho as you could want.


> 1. Total appx 200-300 data entry screens & reports

That should be fine.  If the views are distinct, you might put some time
into deriving something from ViewGenerator.  If there is a possibility
for reuse, reference views might be of great help to you.

For very complex views and/or for running on slow machines (in some
situations, I am happy to have 500 MHz Celerons), I do some lazy
realization of views, but that is quite easy to do.


> 2. 2-3 developers working

When *I* have help, it is usually in the form of graduate students, and
I send them off with an image and a mission.  Their goal, with daily or
per-need guidance, is to present me with what I need to load to benefit
from their work.  When I'm happy, I load the code and send them on a new
task.

Others here can tell you about more traditional solutions.  AFAIK, they
work; I simply have not hit the need for them.


> 3. Mostly data-in / data-out functions against almost
>       all known RDBMSs

Depending on how fancy you get with SQL, you might need to tweak it per
DBMS, but you already know that :)


> 4. Several different apps with same style / features

You might look for a recent thread on components vs. monolithic
executables.  Both approaches are available to you.


> 5. Ok... purely win enviroment (sacrificed)

How so?  Please offer a list - no flame wars.



> What are we loosing (just to be prepared)

Buffer overruns, wild pointers, memory leaks, recompiling because you
forgot to make some function virtual, etc. :)  Humor aside, I am a bad
person to answer this, because I don't see much of value that is not
available with Dolphin - except an escape route to Linux.  The VM is not
multi-threaded, but that is a mixed bag.  One can overlap many calls to
DLLs, which is a way of saying "you can get them to run on a separate OS
threaed".  One cannot overlap calls to ActiveX components, but I have
not been limited by that, in large part because I use very few of them.
  There is a recent thread on that too.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Sanjay Minni wrote:

> This is an honest question / no flame wars etc

Oh, we're all much too nice around here for that ;-)


> Considering all factors for a developer shop -
> Is Dolphin good enough for developing complete integrated
> business apps for small & medium scale organisations
> I mean compared to other more macho Smalltalk's

In general, I don't see any reason to expect that it lacks the "grunt" for
these purposes.

The following is, of course, just personal opinion.  (And be warned, I haven't
used Dolphin for a business app myself, although it'd be my first choice if I
ever had to write one...)


> 1. Total appx 200-300 data entry screens & reports

With that many "screens" you might find the default method of composing Views
in the View Composer to be sub-optimal.  Presumably there is a great deal of
repetition which you could better handle by building Views programmatically,
rather than by the GUI in the View Composer.  There are no significant barriers
to doing so, but it will require a greater knowledge of MVP, hence a longer
learning curve.  But either way (using the VC, or creating the UI from code) it
is easy to produce very nice UIs with Dolphin.

The "report" requirement may be the most problematical.  Dolphin doesn't come
with a report writer, and the printing facilities are not strong
out-of-the-box.  It is /possible/ to do arbitrarily complicated printing, and
people have used Dolphin for business printing, but you'll have to build (or
borrow) quite a lot of supporting stuff that you might hope to find provided
for you.  That said, I don't think that generating/printing your own reports is
a particularly productive architecture (no matter what language or system you
are using), it is generally better to use a separate report writer that reads
your database(s) directly.  You may find that Dolphin's COM integration makes
it particularly easy to integrate third-party solutions (Crystal Reports, say)
but it's not something I've ever tried.

But still, the printing support is what I'd look at hardest before committing
to Dolphin.


> 2. 2-3 developers working

There is no "team support" in the box.  However there are third party
contributions in this area.  I like STS myself (a commercial product but not
staggeringly expensive).   I believe that there are integrations with some
external SCC systems available too.


> 3. Mostly data-in / data-out functions against almost
>       all known RDBMSs

Dolphin comes with the choice of ODBC- and ADO- based database access.  I have
only used the ODBC flavour myself, but found that very smooth.   The potential
problem is that you are limited by the quality of the ODBC or ADO drivers for
any given database.  ASAIK, these are usually available and work well, but
there may be exceptions.  (The MS driver for Paradox seems to be problematical,
for instance).


> What are we loosing (just to be prepared)

;-)

Compared to, say, VW, Dolphin doesn't have as large a community, so there is
less third party software (commercial or "goodies") available.  And what there
is is quite often a "port" of Squeak or VW code (the free stuff anyway).  That
is offset significantly (more than offset, IMO) by the strong integration with
Windows COM and DLLs, so it is relatively easier to find and use libraries that
are not written in Smalltalk.

In a similar kind of way, VW includes more "enterprisey" stuff in the box.
They seem to be pushing hard to include everything one could need for web
services, for instance.  It doesn't sound as if that's the kind of thing that
you'd be bothered about for your more "traditional"  GUI applications, but the
general point is something to consider.

Another point to consider is whether Dolphin's ability to deal with non-Western
European languages is strong enough for your applications.  Dolphin is very
weak in this area[*], but then, I don't know how strong the big name Smalltalks
are.  Something to consider anyway.

[*] basically you are limited to 8-bit characters, and strings.

HTH

    -- chris

Chris,

> > 1. Total appx 200-300 data entry screens & reports
>
> With that many "screens" you might find the default method of composing
Views
> in the View Composer to be sub-optimal.  Presumably there is a great deal
of
> repetition which you could better handle by building Views
programmatically,
> rather than by the GUI in the View Composer.  There are no significant
barriers
> to doing so, but it will require a greater knowledge of MVP, hence a
longer
> learning curve.

My ViewGenerator and friends should take care of the grunt detail, as long
as the default layout is satisfactory.  One could modify it to other things,
but that would take some tweaking.  Sanjay should also expect to subclass
ViewGenerator to contain, read, or iterate some form of meta data.

FWIW (and by no means surprising), I am slowly settling on a separate
hierarchy of factory/renderer classes that use Smalltalk methods to build
various things, including input to a ViewGenerator subclass.  The latter is
heavily customized to my environment, but it would not be too hard to
establish something similar.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> > 5. Ok... purely win enviroment (sacrificed)
>
> How so?  Please offer a list - no flame wars.

I meant Win and those that matter

Win only
   Dolphin     St/MT

Win+Linux
   VW    Squeak    St/X    VA

Actually would be considering between
   Dolphin  (++small compact neat economical,
                   --performance against databases ?  No linux (does not
matter as of now))
   VW       (Big brother
                  -- Licencing !!!)
   Squeak  (could not get used to the environment
                 too gaudy, would like something neater and crisper
                 so let go)

Sanjay




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/04

Hi , all.

I solve the report problem using reStore to interecting with RDBMS and
crystal or component one to design and execute the reports.
Both productos works ok . I prefer crystal because is more powerfull than
component one.

Pablo

"Chris Uppal" <[hidden email]> escribió en el
mensaje news:[hidden email]... haven't
> used Dolphin for a business app myself, although it'd be my first choice
if I
> ever had to write one...)
>
>
> > 1. Total appx 200-300 data entry screens & reports
>
> With that many "screens" you might find the default method of composing
Views
> in the View Composer to be sub-optimal.  Presumably there is a great deal
of
> repetition which you could better handle by building Views
programmatically,
> rather than by the GUI in the View Composer.  There are no significant
barriers
> to doing so, but it will require a greater knowledge of MVP, hence a
longer
> learning curve.  But either way (using the VC, or creating the UI from
code) it
> is easy to produce very nice UIs with Dolphin.
>
> The "report" requirement may be the most problematical.  Dolphin doesn't
come
> with a report writer, and the printing facilities are not strong
> out-of-the-box.  It is /possible/ to do arbitrarily complicated printing,
and
> people have used Dolphin for business printing, but you'll have to build
(or
> borrow) quite a lot of supporting stuff that you might hope to find
provided
> for you.  That said, I don't think that generating/printing your own
reports is
> a particularly productive architecture (no matter what language or system
you
> are using), it is generally better to use a separate report writer that
reads
> your database(s) directly.  You may find that Dolphin's COM integration
makes
> it particularly easy to integrate third-party solutions (Crystal Reports,
say)
> but it's not something I've ever tried.
>
> But still, the printing support is what I'd look at hardest before
committing
> to Dolphin.
>
>
> > 2. 2-3 developers working
>
> There is no "team support" in the box.  However there are third party
> contributions in this area.  I like STS myself (a commercial product but
not
> staggeringly expensive).   I believe that there are integrations with some
> external SCC systems available too.
>
>
> > 3. Mostly data-in / data-out functions against almost
> >       all known RDBMSs
>
> Dolphin comes with the choice of ODBC- and ADO- based database access.  I
have
> only used the ODBC flavour myself, but found that very smooth.   The
potential
> problem is that you are limited by the quality of the ODBC or ADO drivers
for
> any given database.  ASAIK, these are usually available and work well, but
> there may be exceptions.  (The MS driver for Paradox seems to be
problematical,
> for instance).
>
>
> > What are we loosing (just to be prepared)
>
> ;-)
>
> Compared to, say, VW, Dolphin doesn't have as large a community, so there
is
> less third party software (commercial or "goodies") available.  And what
there
> is is quite often a "port" of Squeak or VW code (the free stuff anyway).
That
> is offset significantly (more than offset, IMO) by the strong integration
with
> Windows COM and DLLs, so it is relatively easier to find and use libraries
that
> are not written in Smalltalk.
>
> In a similar kind of way, VW includes more "enterprisey" stuff in the box.
> They seem to be pushing hard to include everything one could need for web
> services, for instance.  It doesn't sound as if that's the kind of thing
that
> you'd be bothered about for your more "traditional"  GUI applications, but
the
> general point is something to consider.
>
> Another point to consider is whether Dolphin's ability to deal with
non-Western
> European languages is strong enough for your applications.  Dolphin is
very
> weak in this area[*], but then, I don't know how strong the big name
Smalltalks

Other dolphin limitation i found is a carency of DST framework. But in many
cases it is not completally necessary.

Pablo
"Pablo Digonzelli" <[hidden email]> escribió en el mensaje
news:[hidden email]... for deal printing,
> and
> > people have used Dolphin for business printing, but you'll have to build
> (or
> > borrow) quite a lot of supporting stuff that you might hope to find
> provided
> > for you.  That said, I don't think that generating/printing your own
> reports is
> > a particularly productive architecture (no matter what language or
system
> you
> > are using), it is generally better to use a separate report writer that
> reads
> > your database(s) directly.  You may find that Dolphin's COM integration
> makes
> > it particularly easy to integrate third-party solutions (Crystal
Reports, some
> > external SCC systems available too.
> >
> >
> > > 3. Mostly data-in / data-out functions against almost
> > >       all known RDBMSs
> >
> > Dolphin comes with the choice of ODBC- and ADO- based database access.
I
> have
> > only used the ODBC flavour myself, but found that very smooth.   The
> potential
> > problem is that you are limited by the quality of the ODBC or ADO
drivers
> for
> > any given database.  ASAIK, these are usually available and work well,
but there
> is
> > less third party software (commercial or "goodies") available.  And what
> there
> > is is quite often a "port" of Squeak or VW code (the free stuff anyway).
> That
> > is offset significantly (more than offset, IMO) by the strong
integration
> with
> > Windows COM and DLLs, so it is relatively easier to find and use
libraries
> that
> > are not written in Smalltalk.
> >
> > In a similar kind of way, VW includes more "enterprisey" stuff in the
box.
> > They seem to be pushing hard to include everything one could need for
web
> > services, for instance.  It doesn't sound as if that's the kind of thing
> that
> > you'd be bothered about for your more "traditional"  GUI applications,
but

Sanjay,

>>>5. Ok... purely win enviroment (sacrificed)
>>
>>How so?  Please offer a list - no flame wars.
>
> I meant Win and those that matter

I thought you were saying Dolphin was lacking in its Windows
integration, which one can probably argue, but IMHO is unlikely to
adversely affect many users.  For example, Dolphin does not have a
framework for OLE server items, but how many of those does one really need?

I agree that Linux is important, and continue to hope for an Object Arts
Smalltalk for Linux.  IMHO, it should not be a port of Dolphin, but I
would expect OA to take full advantage of the Dolphin image, the IDE,
and probably parts of the VM.


>    VW       (Big brother
>                   -- Licencing !!!)

Agreed.  It is sad too, because Cincom should be big enough to keep VW
alive by itself, on the grounds of "we can't afford to let this thing
go".  That is not to say that they should open source it, or otherwise
give it away, but they could certainly put a price tag on it and just
sell licenses.  They could charge extra for support - fair is fair.  I
don't know about you, but I can't go to my department's accountant with
"what's it worth to you" :(



>    Squeak  (could not get used to the environment
>                  too gaudy, would like something neater and crisper
>                  so let go)

Understood, but the UI can be fixed.  Look at Zurgle for proof.  Zurgle
does a little too much, and sadly emulates XP, but it is quite
impressive.  Something similar needs to be done to allow (unavoidable)
forms-based stuff to be created.  With the ability to run on Windows,
Linux, and others, and without runtime fees, Squeak is worth watching.
They are also getting very close to unicode, and have 64 bit VMs running
for those who are so inclined.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:ch595u$lea$[hidden email]...
> I agree that Linux is important, and continue to hope for an Object Arts
> Smalltalk for Linux.  IMHO, it should not be a port of Dolphin, but I
> would expect OA to take full advantage of the Dolphin image, the IDE,
> and probably parts of the VM.

Just thinking aloud, maybe ability to deploy "console" apps on Linux would
be a good start? Linux is still used mostly for server based stuff where
console apps are just fine, and maybe it would be significantly less work
for such restricted port?

rush
--
http://www.templatetamer.com/

You have my vote on this !

Less enumerate basic minimal subsystems:
-sockets
-files
-standard input output (cosole text)
what else?

Assuming this feature, you can develop on your beloved dolphin image on
windows (IMHO, by far the best user interface in smalltalk ever) the server
applications and put them in production with the linux VM !

berst regards,

--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar

"rush" <[hidden email]> escribió en el mensaje
news:ch6ljn$52b$[hidden email]...

Dear Sanjay,

    I been using Dolphin ST for some years and the productivity is great,
the quality of software you can make is amazing.

    My experience with this smalltalk is the one that has more productivty
and "user friendlyness" that I've seen. This support newsgroup (the people
that forms it) is the outstanding.

    Access to RBBMS should not be a problem because of the ODBC conections.
The problem with RDBMS is with the technology itself. If you have the
freedom of doing so, consider the use of ODBMS for complex applications
instead of RDBMS. Your learning curve will be a little harder at first but
by far is convenient at the medium and long run.

    What you'll loose? You will loose any motivation of using PRE
object-environments technologies and all it's vicious problems. Offcourse
you will have to deal with new problems, but as a consolation, them by
experience, are 90% in the conceptual domain and 10% in the technical
domain. By now, ST is the best informatical thing I ever known, and as I
said Dolphin the friendliest,

    best regards,

--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar


"Sanjay Minni" <[hidden email]> escribió en el mensaje
news:[hidden email]...

ODBMS/RDBMS

For very budget oriented mass deployed
(if possible download and use) apps

1. are there any ODBMS engines
2. Does Postgres come in the picture

Regards
Sanjay

"Sebastián Sastre" <[hidden email]> wrote in message
news:[hidden email]... conections.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/04

> 1. are there any ODBMS engines

1. You can use OmniBase (www.gorisek.com).
2. You can use GemStone/S. (http://www.gemstone.com/products/smalltalk/)

Regards Bruno

For embedded databases (under Windows) you might consider
Firebird-DB, which has a pretty good ODBC API interface
and can be totally embedded within your windows application.

On the other hand. From my experience: never use an OODBMS
unless you have ALL source code and you do not depend on
any vendors -especially if you use a niche language like
Smalltalk. I've been in a project, where the vendors shut
down its Smalltalk support in the beginning of the Java hype
due to the vanishing Smalltalk market. Then you're lost.

Therefore I try to use a RDBMS whenever possible.

RDBMS are perhaps a little bit strange for OO programming,
but one can get very good speed - but this means, that one
has to ACCEPT the fact, that it's a relational database
and not programmed against it.

Marten

Sanjay Minni schrieb:

> ODBMS/RDBMS
>
> For very budget oriented mass deployed
> (if possible download and use) apps
>
> 1. are there any ODBMS engines
> 2. Does Postgres come in the picture
>

> On the other hand. From my experience: never use an OODBMS
> unless you have ALL source code and you do not depend on
> any vendors -especially if you use a niche language like
> Smalltalk. I've been in a project, where the vendors shut
> down its Smalltalk support in the beginning of the Java hype
> due to the vanishing Smalltalk market. Then you're lost.

That's a pity

>
> Therefore I try to use a RDBMS whenever possible.
Marten, I undestand, but consider that is good to be informed/prepared about
the so called post-relational era.

best regards,

--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar