database applications

Hi All!
I'm evaluating Dolphin 5. I like Smalltalk language also has understood its
simplicity and power.
But I disappointed in occasion of creation of the GUI for database
applications. Here the basic moments :

- Absent in standart class library something like TableModel ( or DataTable
in .Net  or Dataset in Delphi or Recordset in ADO).

- !!!!!! Absent editable DataGrid for representing and editing data from
TableModel. Its very important!!!

- Creation of the interface seemed to me complex enough. Especially if to
compare for example with Delphi. Where I just put controls on form
(controls - a la View) and bind them to DataField from Dataset ( a la
model). "Bind" - it's simple set properties (DataField, DataSource) for
control from lists. Simple and good DataBinding techics - absent in Dolphin.

- MVP - it's good, but often need simple stuffs like mainstream IDE's. I
mean : put controls on form, set properties (from lists of values), control
has events, write event handlers for controls. That well known technics for
many people and to break a barrier of studying of a new paradigm demands
time.  I think this barrier to high for mass learning Dolphin. It simply
stops programmers from the further studying a product.

For example - when I first time try Delphi, I maked simple DB applications
about 1 hour. With Dolphin I can't do it some days.
But make complex logic and algoritms with Smalltalk - pleasure!
But GUI ... :(((

May be Dolphin not intended for creation database applications?

Pavel
Russia

PS For information - I'm system architecter, my expirience about 8 years
(Delphi (GUI, ActiveX) , VB, VBA,  MS SQL Server, .Net, Client-server
technology).

Sorry for my English.

Pavel,
Welcome to Smalltalk and Dolphin!
The problem you describe is a recognized one in the Smalltalk community and
(I believe) has two general roots. One is related to the observation you
made that Smalltalk is good for complex logic. There is a sense in which
Smalltalk is good at complex problems, but that makes it sometimes a bit
cumbersome at simple problems (there is still room in the solution space for
scripting languages and tools that solve trivial problems). For anything
more than a throw-away project (i.e., if there will be any maintenance or
enhancements), Smalltalk is worth it.
The other root of the problem is related to the difficulty of converting
objects to relations. With an appropriately-normalized database, you will
have a number of joins involved in reading anything more than trivial data.
When that is converted to objects (whether Smalltalk or Java or ...) you
will have done some complex operations (at which Smalltalk excels).
Having said all that, I'd still choose Dolphin for the GUI front-end for a
Windows client and a relational database application. The "Enhanced List
View" provides a good table widget (though it is read-only; no editing in
place), and the DBConnection and related classes provide a good access to
the database.
By the way, if you are dealing with a really complex problem and aren't tied
to a relational database, check out
http://www.gemstone.com/products/smalltalk/ (disclosure--they are my
employer ;-).
James Foster

"Pavel" <[hidden email]> wrote in message
news:436b64aa$[hidden email]...

Hello James,

> By the way, if you are dealing with a really complex problem and
> aren't tied
> to a relational database, check out
> http://www.gemstone.com/products/smalltalk/ (disclosure--they are my
> employer ;-).


Is gemstone compatible with Dolphin? O:-)

Thanks

> By the way, if you are dealing with a really complex problem and aren't
tied
> to a relational database, check out
> http://www.gemstone.com/products/smalltalk/ (disclosure--they are my
> employer ;-).

Tnx, for reply. I known about GemStone/S. But I didn't evalueted it
ecause  -  absent online product documentation at site,  and lazy pass
procedure for evaluation request :).  Also We have applications of using
relational DB Severs and migration for us to another OODB is practically
unreal at that moment.

Pavel,
[...]
> - !!!!!! Absent editable DataGrid for representing and editing data from
> TableModel. Its very important!!!
[...]
Take a look at this: http://www.solutionsoft.co.uk/widgets/index.htm.  It's
a free goodie that could be handy for your purposes.

Of course, creating a trivial DB app in Dolphin is still harder than in VB
(or Access, if you just want to edit tabular data), but, like James Foster,
I think that apparent advantage goes away as an application becomes more
complex.

HTH,

Don

"Don Rylander" <[hidden email]>
ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:436b8da4$[hidden email]...
> Take a look at this: http://www.solutionsoft.co.uk/widgets/index.htm.
It's
> a free goodie that could be handy for your purposes.
>
Tnx for reply. I already tried it. I would would like something like
comercial http://www.instantiations.com/VAST/wkp.htm

Fernando Rodríguez escribió:
Yes.

I have a GemBuilder (a beta version) running on Dolphin 5 with GemStone 6.

When OA release D6 i will upgrade the GemBuilder to D6.

Regards Bruno

Pavel,

> I'm evaluating Dolphin 5. I like Smalltalk language also has understood its
> simplicity and power.
> But I disappointed in occasion of creation of the GUI for database
> applications. Here the basic moments :
>
> - Absent in standart class library something like TableModel ( or DataTable
> in .Net  or Dataset in Delphi or Recordset in ADO).

It is true that Dolphin probably should include something, but the
reality is that Smalltalk's dynamic typing makes it quite easy to create
something.  The tricky part is the queries that go into it.



> - !!!!!! Absent editable DataGrid for representing and editing data from
> TableModel. Its very important!!!

No argument.


> - Creation of the interface seemed to me complex enough. Especially if to
> compare for example with Delphi. Where I just put controls on form
> (controls - a la View) and bind them to DataField from Dataset ( a la
> model). "Bind" - it's simple set properties (DataField, DataSource) for
> control from lists. Simple and good DataBinding techics - absent in Dolphin.

This is a common MVP newbie complaint, independent of databases.  Just
as common is a later reaction along the lines of "why was that so hard
last week?".  MVP is like Mark Twain's father: it gets smarter as you go.



> - MVP - it's good, but often need simple stuffs like mainstream IDE's. I
> mean : put controls on form, set properties (from lists of values), control
> has events, write event handlers for controls. That well known technics for
> many people and to break a barrier of studying of a new paradigm demands
> time.  I think this barrier to high for mass learning Dolphin. It simply
> stops programmers from the further studying a product.

Things could be better via IDE extensions for the VC and CHB/SB, but the
  tools exist even in the base system.  They demand some study and
practice, but believe me, they work well.

Search the archives for ViewGenerator.  Note that

   http://www.cjd77.com/smalltalk/PresenterGenTool.htm

is more likely to meet your short term needs.  When you want something
that can place controls for a table and beyond, start with
ViewGenerator.  It will take some work to get it right, but it can do it.


> May be Dolphin not intended for creation database applications?

Note that some of the Smalltalk tools to which you are comparing cost
easily five to ten times the sticker price on DPRO.  Dolphin can indeed
create very viable database software, but you will need to write some
glue yourself, or buy things like ReStore to fill the gaps.

Have a good one,

Bill

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

Fernando,

GemStone Systems does not market a "GBS" (GemBuilder/Smalltalk) that
integrates directly with the Dolphin environment (as they do for VW and VA).
At least one person has done their own (see Bruno's post). Another
alternative is to forego the transparent replication feature and communicate
with GemStone/S from Dolphin using the C DLL wrapper. A side-effect of this
approach is that you tend to push more of the behavior into the application
server and make the client application (with the user interface) simpler. It
wouldn't be best for every situation, but it is working well for me right
now.

James

"Fernando Rodríguez" <[hidden email]> wrote in message
news:[hidden email]...

"Pavel" <[hidden email]> wrote in message
news:436b64aa$[hidden email]...
> Hi All!
> I'm evaluating Dolphin 5. I like Smalltalk language also has understood
> its
> simplicity and power.
> But I disappointed in occasion of creation of the GUI for database
> applications. ....

It may be unpalatable, but I'm afraid economics have a part to play here. I
absolutelty don't doubt that you can solve any problem cheaper in Smalltalk,
unless someone else has already largely solved problem in the language
against which you are comparing it. And the truth is that for the most part
other people have already solved that problem in any other language but
Smalltalk.

Smalltalk is without doubt the most productive (and enjoyable) language in
which I have ever programmed. There are many languagues I've never touched,
but of those I have I'd rather use Smalltalk any time. So if you want to
solve a problem that is not something you'd find in 10 minutes on Google,
you too should consider it.

If we're honest however, most programming problems are mundane, and mundane
problems attract mundane solutions. Certainly you will find no end of cheap
and fast solutions to typical business solutions.

The real point is that these are mundane solutions. Someone (often
Microsoft) has gone out of their way to make it easier to develop mundane
solutions in mundane languages.  That's fine, if not for me.

Smalltalk cannot compete against tools and languages from the traditional
mindset espoused by IBM, Sun and Microsoft. However if you want to step
outside the box it has no equal, even after 25 years.

Regards

Blair

(I suppose I'm just trying to say that if all you want to do is develop data
movement/transformation apps, don't bother with Smalltalk. There are
optimised solutions for this. If on the other hand your problem has hard
logic you just can't get right, it may well be because you are using a
language optimised for that)

Blair,

> (I suppose I'm just trying to say that if all you want to do is develop data
> movement/transformation apps, don't bother with Smalltalk. There are
> optimised solutions for this. If on the other hand your problem has hard
> logic you just can't get right, it may well be because you are using a
> language optimised for that)

Very well said, up to the post-script :)  I would argue that Smalltalk
is also great for mundane tasks, provided one focuses on toolmaking vs.
directly programming the details.  Though I will admit that for a
Smalltalk newbie using Dolphin or other dialects w/o expensive add-ons,
that probably translates into what you've said.

Have a good one,

Bill


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

I think Pavel's original note is correct.
You start by learning this beautiful smalltalk language in a day.  It
is so quick, terse, powerful, and consistent.  And the Dolphin IDE is
beautiful.  And the unit testing is so elegant.  Then one gets into
making the MVP Gui, the awkward source code control options, and
database integration all of which have steeper learning curves than the
language itself.  In other words the elegance of the langague and IDE
is undermined by how long it takes to make real simple applications.

Ruby (a somewhat bastar_ized version of smalltalk) nevertheless seems
to have helped it's mindshare by integrating with web database
technology (Ruby on Rails).

In order to get to point where one can write complex applications using
all of Dolphin Smalltalk's power, one must pass through the land of
mundane applications.  I am looking forward to using Dolphin 6, and
hope there will continue to be efforts to ease the learning curve
out-of-the-box for new users such as Pavel.


Bill Schwab wrote:

Your post-script Blair is harsh to new people using Dolphin Smalltalk.
Moreover, I think is not necessary true. Having objects all around you
should make your life easy if you are trying to build a "data
movement/transformation" application.

Database connections, queries, rows, datagrids: all are objects and it
should be easier to implement "simple" applications with Smalltalk than
implement complicated applications.

I know the case of a well-known company that started developing in
Enfin Smalltalk (years ago) because the managers saw the potential of
developing simple ad-hoc query/reporting applications that display
results in grids or charts. I know that we can do the same or better by
using COM with office applications or 3rd party widgets.  But Pavel was
right, Dolphin does not provide such solutions or documentation on how
to do it out of the box.

Federico

Federico,

> Your post-script Blair is harsh to new people using Dolphin Smalltalk.
> Moreover, I think is not necessary true. Having objects all around you
> should make your life easy if you are trying to build a "data
> movement/transformation" application.
>
> Database connections, queries, rows, datagrids: all are objects and it
> should be easier to implement "simple" applications with Smalltalk than
> implement complicated applications.

I suspect Blair was simply being candid about the current state of
Dolphin's out of the box support for such things, though I would have
focused it differently that he did.


> I know the case of a well-known company that started developing in
> Enfin Smalltalk (years ago) because the managers saw the potential of
> developing simple ad-hoc query/reporting applications that display
> results in grids or charts. I know that we can do the same or better by
> using COM with office applications or 3rd party widgets.

=:0  If you suggest sending to MS Office to the rescue, _then_ we have a
disagreement :)  What we need is a Moen-tree like grid implemented in
Dolphin.  Better still would be to have a refactoring of the Moen tree
code to yield a pluggable framework for creating similar high-quality,
fast, robust widgets w/o resorting to external components.


 > But Pavel was
> right, Dolphin does not provide such solutions or documentation on how
> to do it out of the box.

Agreed.  However, I still suggest that he look at the few things that
lean in the direction of what he wants, consider your point that dynamic
typing files off many of the rough edges that require framework support
in other languages, and that he compare the costs and benefits of
rolling up his own tools in Dolphin vs. buying point and shoot tools
from other vendors.  No argument, that's a tall order for a newbie to
the language.

Have a good one,

Bill

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