> For those who don't know about microsoft's web application archetecture, it uses
> extensive client-side processing.
> The microsoft standard archetecture seems to want to use COM to implement it's data
> access. Quite how this will ever work robustly either on a large network or on a
> non-winX machine I don't know.
Microsoft's entire mission seems to be to build programming practices around making it
impossible to deploy applications to machines without Microsoft software, and to get
as many people developing software this way as possible. Good for them, but I do not
buy in to it.
It seems like there is a right way and a Microsoft way to do everything.
>>> Robert Burrell Donkin <[EMAIL PROTECTED]> 10/10/2000 5:02:14 PM >>>
(I promise that I've read my mail before sending it this time.)
Jon Stevens wrote:
> on 10/8/2000 3:16 PM, "Robert Burrell Donkin" <[EMAIL PROTECTED]>
> wrote:
>
> > I did some stuff (messing around) a bit ago which was sort of rang a bell
> > with the emails from Mike from the navy. It's very, very easy to knock up
> > library routines using which work against SQL RDBMSs and return ECS
> > elements. Example - the class input form. I was really surprised how quickly
> > you could produce the infamous data-bound multi-choice combo button by
> > writing library functions returning ECS classes.
>
> True...I'm not suggesting that you do otherwise...in fact, that is a
> *perfect* example of how to use ECS.
>
> > You see, I'd rather use
> > servlets than use the client-side scripting alternatives from microsoft (or
> > whoever) - and those are (unfortunately) the enemy, not turbine etc.
>
> client side? huh? where does that come into play here?
Out there where I work, foolish managers the microsoft and read the hype and think
- we can use our VB developers to web-enable our applications. I have a friend who
makes a fortune sorting out the crashs caused by this approach...
For those who don't know about microsoft's web application archetecture, it uses
extensive client-side processing.
The microsoft standard archetecture seems to want to use COM to implement it's data
access. Quite how this will ever work robustly either on a large network or on a
non-winX machine I don't know.
I have heard that it *does* work well for win2000 machines....
I was (inarticulately) trying to contrast using ECS in servlets (or any other
server-side technology, for that matter) with this alternative approach.
>
>
> > I know
> > all the advantages of OO databases - but most boss's will only look at a
> > technology like servlets if you can say - it runs against Oracle.
>
> Right. Hence the reason for my original question. I was trying to get more
> detail into what people meant.
>
> > I've
> > looked at Oracle's java generation technology - not bad. But (in my opinion
> > - and have done 2 years of code generation) they don't make the use they
> > should do of good library code and inheritance. They're a bit like a child
> > with a new toy and want to generate everything (even when more classic oop
> > techniques would produce better code).
>
> ? We weren't talking about using code generators.
Code generation is Oracle's approach to server-side java connectivity. JDeveloper
generates data access code based on wizards.
This is another approach to the same general problem.
(Apologies, I tend to ramble)
>
>
> > don't get me wrong - I've aware (though probably not as aware as I should have
> > been before this thread!) of turbine. Unfortunately most coder's don't get the
> > chance to play with stuff like that on work time.
>
> Huh? But you get a chance to play with ECS?
>
Yes. I played about with some stuff pretty similar to Michael P. McCutcheon a few
months . I sort of got into this thread since I'd found them surprisingly easy to
write using ECS :-)
>
> > I sometimes think that gurus
> > telling newbies to go away and learn what is quite a sophisticated framework
> > can be counterproductive.
>
> Lets see, the decision is that you learn a commercial closed source
> sophisticated framework or you learn a free open source sophisticated
> framework. Sorry, but the choice is pretty obvious to me.
>
Unfortunately, I've observed that for many developers, management would reverse
that order! Yes, I would personally prefer to work in the second way but I don't
have much of a choice unless I want to flip burgers for a living! I've observed
that you have to fight twice as hard to get a superior technology accepted when
it's free.
The thing that impresses management most is *quick* code. Say that you can use
Servlets to get the job done in half the time that it would take to implement using
IIS - and then they listen.
Microsoft leverage the fact that there are millions of visual basic developers
worldwide to sell a relatively immature and bug-riden technology to managers.
Microsoft can shout much louder than the open source community. Say to management
that you know a brilliant framework that'll only take a few weeks to learn and
it'll get you nowhere! It's not good enough to have a better technology, you need
an army of developers. Acceptance of means giving newbies ways that they can get
stuff working quickly! Don't worry - once they start looking to move their projects
forward they will come looking for more sophisticated development frameworks.
>
> > (this is the JServ vs Tomcat arguement)
>
> Huh? What JServ vs. Tomcat argument? There is no argument there.
>
(apolgies for not reading my email before sending it... I had the flu but that's no
excuse)
My opinion is that newbies should be recommended to begin with JServ not tomcat.
It's easier to install and *much* simpler to get simple servlets running. It's not
as sophicated but simplicity has it's own merits. When they realise that they
*need* Tomcat then they'll move. (Before you ask I have installed both and have
been subscribed to the mailing lists for quite some time.)
>
> > Yes, point
> > them in the direction towards enlightment, but if using ECSs in servlets maybe
> > in the way that I outlined above (or - any other way for that matter) helps
> > them get their job done and gets the technology out there then that's
> > something to be supporting.
>
> I never was not supporting your example use of it. I support it quite a bit.
>
> > It's easier to get commercial acceptance of
> > something that can be shown to work quickly than telling your boss that you've
> > got a framework that'll take four weeks to learn but will solve all their
> > problems. (Let's face it - microsoft and oracle are much better at this type
> > of hype than any open source organisation). Coders will learn the wisdom of
> > your words in there own time. Hell, they might even surprise you with some new
> > innovation (us all! myself never so humble).
>
> At this point, I don't think that Turbine (with the TDK) takes any longer to
> learn than any other commercial closed source framework.
My point is that I'd recommend newbies not to start with a framework at all!
Frameworks can be a steep learning curve. Alright if it's at work, but at home I
guess that you'd have to be pretty motivated...
Point them to the next stage, but start it simple.
To get back to the original start of the thread, the whole apache-java-jakata-xml
needs more stuff like that!
I have a suggestion - why not set up a form which would allow people like Basil
Bourque to post anonymous links to tutorial pages - and indeed anything they want
concerning the technologies being developed. Have a page which displays all these
links.
...just an idea...
robert
>
>
> > (... I love dialectic reasoning...finding the truth by arguing extremes...so
> > please don't get personally offended ;-)
>
> I never do, but people like to interpret my replies as if I do.
>
> -jon
>
> --
> http://scarab.tigris.org/ | http://noodle.tigris.org/
> http://java.apache.org/ | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/ | http://www.sourcexchange.com/
>
> --
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
