Kito D. Mann wrote: <SNIP>
The main difference between the component and taglib approach is that in the component world, all of this functionality would be implemented by a component/renderer pair. The component itself would be a JavaBean, so it'd have methods, properties, and events, and integrate with tools. You could even have a JavaBeans customizer that would allow you to find and connect to the data source with a wizard interface. You could also develop different renderers, so perhaps one would output HTML and another might work for a WML device.
<SNIP>
It's submarine, but it can fly.... AND it's a lawn mower too. This way every member of the committee gets their feature. We'll think of a use for it later. A grid that displays on my browser; and on my cell phone! This would run great.... in PowerPoint.
Where the C# tutorial!
(of course, vendors do not have to use it later, unlike people that develop OS. Yeah, make it like Swing, lets duplicate that success. I use Eclipse, those silly OS people don't use Swing "standard", they must not be as smart.) I used to use Vendor designed frameworks, and ran away from them to Struts.
Kito D. Mann wrote:
<SNIP>
> There's an example of a much less capable, but similar, component in JSF EA4.
> Kito D. Mann > Author, JSF in Action <SNIP>
Vic:... "less capable", and more complex, now that takes a committee to advise me.
Craig wrote:
<SNIP>
>some commenters fail to remember what "early access" means -- it's not done yet.
<SNIP>
So we can't critisize it? But you can market it? Positive reviews are OK? I have heard wait till next version from Sun. There are a lot of promisses made, like ASF version of JSF, and ....
"Submarines and lawn mowers" isn't criticism ... it's emotional grandstanding.
Craig wrote (in another thread on EJB):
<SNIP>
Struts doesn't have a UI component model at all (the HTML tags do not count -- they are simply ways to render simple input fields -- which is why we have to work so hard at things like tree controls and grids), but shines in its overall framework characteristics.
<SNIP>
??
Vic: "HTML tags are a simple way to render input tags" ... simple as in simple is bad?
Simple is great if your needs are simple ... when your needs grow then you need something else -- tree controls, menus, editable tables, and so on are all things that have to be bolted together, and aren't necessarily designed to interoperate. Let alone provide sufficient metadata about themselves so that they will make it possible for tools to provide a rich experience. Where's the property sheet that an IDE can use to drag one of these tags onto a pallete and the configure it?
(Also I use a nice open source tag for tree that emits .js http://www.guydavis.ca/projects/oss/tags)
I agree with Matt on this issue.
Hopefully it's OK that I stay with http://displaytag.sf.net and Struts, and JSTL/HTML for Multi Row Updates/Validation. Until Flash Grid takes over, executing on a client's browser, and not on the server.
Be my guest.
(See, I did not even bring up vendor licensing or Sun's poor finance ;-))
And you even forgot JSR-168 too :-)
Go Java!
KISS,
.V
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
