=?iso-8859-1?Q?Re:_[U2]_Where_Will_the_=2ENET_Apps_Live_??=
Will, What you're talking about (as you know full well I'm just adding my 2c) is a proper division of labour: the heart of good client/server. We have the advantage in this sector that at least we don't need a separate third tier for the business logic, since we already have that tier inside the database. We've learnt in this sector about the advantages of using soft coded definitions rather than hard coding screens - even when those definitions are generated from the likes of SB+ grin. It is a lesson a lot of the rest of the computer industry never really took to heart. The fact is that most windows languages - especially VB - are not ultimately suited to applications consisting of many hard coded forms - though the various standard IDE tools seem to direct you down that road. Looking at the way a lot of sites write VB applications is like watching novices hard coding green screens but with text and combo boxes instead of inputs: indeed many sites that stopped hard coding green screens years ago seem to take a step backwards when they take up the Windows GUI. Perhaps it is the scent of RAD that confuses them. Generating Java or VB or Delphi or C# code from definitions - sure, why not? That can be done server side leveraging the advantages of our structures that make it easy to store and parse such definitions. But from a deployment/change control/resource consumption point of view it may be better to build interpreters - screen/menu/print/dialog/list and logic runners picking defintions from the server and ensuring that all definition changes are automatically and instantly reflected by the run machine on the client. Anything that separates out the definitions of the application from the implementation is an essential, and there are many ways to skin that particular moggie. But you are absolutely right that it all begins and ends with the server logic. Get that right, and the choice of front end become pretty much irrelevant. I always tell my clients to build the server first: it is so much easier to verify and QA before the front end is assembled. Unfortunately too many sites still seem to approach it from the other end and end up with garbage and high QA costs. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Full agreement with Brian, Will, and David on separating rules from the UI, which is a concept that many MV developers tend to acknowledge but not apply. Will, I'll see your bet and raise you a few : The concept of compiling rules down to Java is only half of it, the other half is executing them. You're talking about Java triggers where changes in the environment invoke Java code rather than MV BASIC. That concept has been implemented in (I believe) Revelation and jBase but eludes IBM and RD products. (Someone please correct that if I'm wrong, thanks.) If Java were an alternative development language to BASIC, our world would be much more open to mainstream developers than it is now. This is exactly what Oracle has done, allowing Java as an alternative to PL/SQL, and I think it's a great move. I'll summarize a couple related ideas. I hope I'm not being being too vague but this could turn into a whole research paper: - MV environments shouldn't hard code to interface with the BASIC run-time. Since BASIC compiles down to interpreted tokens anyway, we're already running a form of IL in our own environment. Rather than extending U2 or other MV environments to support a single different language, the environments should incorporate and integrate with virtual machines to run both the Java and .NET virtual environments (for bytecode and CIL). This would allow native support for all popular languages and make U2/MV as mainstream as any other DBMS. - Related to separating rules from UI, how about separating the rules from the database? None of the MV providers have shown interest in extracting the BASIC run-time (sans DB) to run in a compact form on the client. No client is 100% thin and some are downright thick. If the U2 BASIC run-time could run in the client then validation could be done there as an alternative to using scripting languages or intricate round trips of data with the server. For validation requiring data access, the client-side environment only needs to implement an internal web service client with a corresponding API on the server. Of course the developer will have to code in a non-persistent mode because things like OPEN and READU wouldn't be processed the same as in a persistent server. - While that concept perpetuates the MV developer's reliance on MV BASIC, which may not be an entirely good thing, we can take it one step further: there's no firm reason for the BASIC compiler to be married to the DBMS either. IBM could offer the BASIC compiler and a run-time for the object as free downloadables (U2Script?), which may get the interest of some mainstream developers - of course they could only access a U2 database on the back end, but isn't that what upselling is all about? :) Sure those concepts have issues. Monolithic development effort? Maybe, maybe not. Would mainstream people appreciate a procedural and non-event-driven language? Well, we do! :) I'm just tossing ideas on the table because all discussions revolve around getting some outside and mainstream language to communicate with the U2 black box but there's rarely discussion of opening components of the box itself to embrace and extend mainstream tools. Tony TG at (remove this) Nebula dash RND dotster com brian-at-brianleach.co.uk |U2UG| wrote: Will, What you're talking about (as you know full well I'm just adding my 2c) is a proper division of labour: the heart of good client/server. We have the advantage in this sector that at least we don't need a separate third tier for the business logic, since we already have that tier inside the database. ...But you are absolutely right that it all begins and ends with the server logic. Get that right, and the choice of front end become pretty much irrelevant. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: =?iso-8859-1?Q?Re:_[U2]_Where_Will_the_=2ENET_Apps_Live_??=
brian, Monday, December 27, 2004, 3:44:01 AM, you wrote: snip bbcu But you are absolutely right that it all begins and ends with the server bbcu logic. Get that right, and the choice of front end become pretty much bbcu irrelevant. I always tell my clients to build the server first: it is bbcu so much easier to verify and QA before the front end is assembled. bbcu Unfortunately too many sites still seem to approach it from the other bbcu end and end up with garbage and high QA costs. Have to disagree a bit with this. Although the backend is very important so is the front end. Knowing your market .. the way users actually do their work for the specific market and tying the two together. That is the challenge. The choice of front ends is just a critical for this portion of the environment. Although Delphi is a brilliant product, OpenInsight is much better for any MV environment. With a native bond to U2 it is just about the perfect tool for MV front end development. Front end does matter. Although you can set a screw with a hammer a screw driver would be the preferred tool g -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ Whenever you are in doubt...apply the first test. Recall the face of the poorest and the weakest man whom you may have seen, and ask yourself if the step you contemplate is going to be any use to him...True development puts first those that society puts last.-Mahatma Gandhi --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
