Re: GSWeb/GDL2 Status

[Thom Cherryhomes]

the big problem I see is.... and you guys really can't dispute this....

Unless you already KNOW how to use EOF and WO....

YOU CAN'T USE THESE TOOLKITS!

They're in my eyes, half done, half baked, missing the other side of
the tools that made these frameworks great in the first place. (I also
submit that WO in general is in desperate need of lessons learned in
the last few years, such as prettier URLs, REST modelling etc.).....
so until these parts are at least functional....these toolkits are
only of use to those of you who live in that little world.

yes, I'm being a snit. All of you have spent just a wee bit too much
time in your ivory towers coding this stuff for your own use.

-Thom


On Nov 21, 2007 4:08 PM, Helge Hess <helge.hess@opengroupware.org> wrote:
> On 21.11.2007, at 21:52, Nicola Pero wrote:
> > I suppose if you want to remove duplication, at this point why not
> > re-base GDL on SQLClient :-)
> >
> > SQLClient provides an SQL library (like JDBC).  It's got a nice
> > simple API
> > precisely designed to let you pipe SQL statements to a database and
> > read results. :-)
>
> Like EOAdaptor. A few categories for your specific needs would have
> done the task. Do you really think that its impossible to inject SQL
> into EOF??? :-)
>
> > GDL provides a full object-to-relational-database framework, which
> > is much more interesting in many ways, and has a much richer set of
> > concepts and tools.
>
> It *also* provides a low-level API. EOF is built in separate layers,
> the "JDBC connect" (adaptor layer) is just one of them.
>
> > But if you don't want any of them, ie, you don't want models, you
> > don't want controls, you don't want associations or EOInterface
> > etc ... then well why use GDL ?
>
> Because GDL also has SQClient builtin for something like 10+ years.
> Just build the EOAdaptor layer as a framework and add the hooks you
> need.
> And why? It should be rather obvious why code reuse is a good thing :-)
>
> [snip]
> > The interface to pipe SQL into the database is not as clean and
> > simple as the SQLClient one, because it's not designed around that
> > concept (in fact, the authors probably despise even the idea that
> > you might be want to write SQL code directly). ;-)
>
> Sorry, but this is utter non-sense. Its like saying that you have to
> use and include AppKit just because you are using Foundation. EOF is
> a layered framework and if you don't need EOInterface, don't link it.
> And if required you could have made it even more modular instead of
> dropping the (well tested!) code.
>
>
> I think the real issue was "finding" the relevant part of EOF. You
> look 5min on the EOF2 API, you get bored and think its overkill
> (because the docs *do* focus on ORM), you don't care and continue
> building own stuff.
>
> Writing the stuff from scratch isn't hard and its fun, so its done
> (wow, that even rhymes ;-) And now that you have it its even easier
> to justify (now that we have its harder to drop it because it would
> just be additional effort)
>
>
> Oh well, oh well, what an evil cycle of utterly useless reinvention :-)
>
> Greets,
>    Helge
> --
> Helge Hess
> http://www.helgehess.eu/
>
>
> _______________________________________________
>
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>