jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph B. Ottinger" <j...@suninternet.com>
Subject Re: ANNOUNCE: Example SQL Taglib for JSP...
Date Tue, 09 May 2000 11:28:15 GMT
On Tue, 9 May 2000, Gal Shachor wrote:
> "Joseph B. Ottinger" wrote:
> > Anyway, on to your points:
> > 1) Java developers aren't hard to come by; such data access beans would be
> > VERY easy for a tool to generate, if a developer isn't handy. (Right,
> > Eduardo?)
> Not so true, I have just spent a day with my sysadmin trying to explain
> him how
> to create a simple report using JSP + Beans + Scriptles and eventually
> wrote him a
> set of custom tags because this is what he can use...

The problem is one of design. I'd advocate a mix of tags and beans,
in the real world - it's easy, it's fun, it's efficient, it's
convenient. Again, see
http://cupid.suninternet.com/phonelist/fates/listfates.jsp for an example.

> He could not use the beans because of the scriptlets! he had lots of
> problems 
> with them (But why do I need to put ; what is this import attribute?
> what is
> this syntax error ....) but he is really comfortable with tags.

*nod* I'm not a fan of scriptlets.

> The point here is that we have in my location many Java developers, but
> you can 
> not (and should not) fork a developer to help someone that got stuck
> because he 
> does not know about Java.

No doubt, and that was never my argument.

> > 2) Too much of an effort? How so? It would seem to me that it'd be ... ah,
> > never mind, I see your point exactly. *shrug* I think reusable components
> > would be better, but... that's just me.
> Tags are VERY reusable, lets assume that you have a set of tags that
> lets you:
> 1. Select something from a data base.
> 2. Enumerate the response.
> 3. Show the specific columns in the current row.
> 
> You can create >50% of your reports with that.

True enough. I still think it's better to have a bean that wraps data,
though, as your data might be *just data* and not *relational data.* It's
convenient to assume everyone's using JDBC, but be real: not everyone
is. EJB allows you to wrap legacy (codasyl? flat file?) data in Java, and
that's a normal business process; using EJB shouldn't be the solution you
turn to when everything else craps out, it should be the *first* solution
you use, and you use other access methods only because you can't manage to
convince the PHB to buy Orion.

> > 1) Woohoo! Then why not use PHP or one of its derivates, which don't even
> > bother to encourage proper design? PHP is designed JUST for this kind of
> > hackery, without all that pesky Java syntax. Plus, PHP is a lot more
> > forgiving of completely crappy designs.
> 
> So you want yet another scripting language for my none programmer?
> Really.
> Also, I would rather work with something that is a standard!

Please note my sarcastic tone; I'm no fan of PHP. I far prefer proper
design.

> > 2) I've no real answer for this, except to possibly ask why it's wise to
> > provide a hammer as a tool for, oh, computer repair - "It probably won't
> > work, but it COULD."
> It does not really matter that this is not the right way. What is
> important is
> that these things happen, and then you need to support it in the
> platform (or 
> JSP will remain the tool for the Java developers).

*nod* although this still rubs me the wrong way.

-----------------------------------------------------------
Joseph B. Ottinger               joeo@cupid.suninternet.com
http://cupid.suninternet.com/~joeo      HOMES.COM Developer


Mime
View raw message