Well, there is the getter-setter design pattern that seems to be required for
the set/get property tags. I find that amazingly useful cuz I'm always writing
the code to do that from session and form values. And what's more, seems like
they're putting the bean away into a session object, then it pops right back up
on the next service request just like I left it. So that saves me from writing
the code that saves every laborious bit of information I want to preserve
across the session and then restores those same laborious bits casting them
appropriately and all that is a drag and you know how quickly programmers get
bored. Poor babies. We get paid well enough you'd think a little laborious
tedium would be a good lesson. But no. I want more classes, fancier api's, more
inscrutable design patterns.
I heard someone somewhat seriously saying that a real (s)he-man programmer uses
every element of the C++ language just because its there, whether it makes
sense or not.
-Roger Kovack
Chris wrote:
> Part II in what's threatening to be my Pedantic Bean Series . . .
>
> When I first read about JSP, and I found out that they use Beans (not
> classes but Beans), I shit myself. Okay, no I didn't, but I was
> displeased because I actually have been a semi-successful freelance Java
> coder since the week Java came out, and I've never written a Bean! I
> always got away with just classes. So I was gonna have to find out
> precisely what a Bean really was and how to actually write one from
> scratch with WinEdit.
>
> I went to Sun's site and downloaded various tutorials and white papers
> and such (kind of a pain - most either didn't say anything or were
> poorly titled instructions on BeanBox - none seemed more recent than
> late 97), I came across the Bean Specification 1.0.1, and I read the
> whole damn thing.
>
> In it, a Bean is never precisely defined (it's a class, no wait, it's an
> object. It "doesn't inherit from any class or interface", hold on, it
> "must implement either Serializable or Externalizable". That was
> frustrating. Also irritating was the spec stressing that a Bean
> basically was a component that can be created and customized with a
> visual tool, and how there were plenty of things (like JDBC) that were
> better off as Class Libraries and not Beans - in other words, Everything
> Shouldn't Be a Bean. All well and good, but then JSP apparantly decides
> everything MUST be a bean - even things that have no use manipulation
> with a visual tool. So that seemed like a bad decision by the JSP guys.
>
> So now I'm frustrated, I've read some stuff that annoyed me (not hard),
> and I STILL don't really know what a bean is or how to write one. So I
> decide I'll just look at Sun's source code examples that ship with the
> JSWDK, and I'll follow their lead.
>
> And guess what?
> They're Not Beans!!!!!!!!!!
>
> They're just plain ol classes, the kind I actually know how to write.
>
> Which brings me to the place I could have started from if I wasn't
> hamming it up . . .
>
> Does JSP really only work with Beans (and not just plain Jane classes),
> and is the JSWDK just being nice (and if so what kind of a reference
> implementation is it? OR is there no Bean requirement at all - and if
> that's true, how come JSP says there is (heck, it calls the tag
> 'jsp:useBean")?
>
> All griping & insufferable garrulity aside, I would kind of like an
> answer.
>
> - Chris
>
> P.S. I STILL don't know how to write a bean
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
