OT FRIDAY: Re: JavaServer Faces
At 08:05 PM 10/9/2003 -0400, you wrote: Yes I too have worked on Microsoft Systems where you drag and drop components into a Frame and voila you have a functional web page. 1)First a general feeling if uneasiness about integrating the classic Monolithic Microsoft Component Structure into a working Distributed Environment The idea of integrating so much functionality to be handled by one component gives me a very uneasy feeling. Well, I think a lot of times how much is "handled" by one component is a matter of the component's design. And when you have a rich set of components to choose from, you can pick more granular ones or more complex ones, depending on your disposition. And, call me crazy, but I have better things to do than write the code necessary to support a full-featured data grid. As the people at companies like Infragistics will tell you, there's a hell of a lot of functionality you can add to a data grid. Personally, I'd rather work on the specific nuances of the system I'm trying to build. For one thing the dependencies between components are not known. In the Microsoft world DB's generally have to be ODBC or not work at all. A more verifiable result is implementing the wrong version of component and you have a disaster.. I'm not quite sure what you're talking about here. Since I did Delphi development, I wasn't aware of any ODBC-specific constraints. My Achilles heel was the Borland Database Engine (BDE). But I won't go into detail about that monstrosity. Using the BDE wasn't a requirement, though, and there were alternative ways to do things. (I think Borland has axed the BDE for good, finally). Also, I wasn't trying to say that Microsoft's way of doing things is better or anything like that. I'm just saying that user interface component-oriented development (RAD, back in the day) yields productivity gains. Microsoft is the most well-known promoter of GUI components, but they're certainly not the only one. 2)Finally I would like to request (Specifically) which IDE's handle JSF today Since JSF isn't even in beta yet, you're not going to find any full-fledged IDEs that support it. My FAQ (http://www.jsfcentral.com/faq/) talks about the companies involved (which includes all of the major Java IDE players), and has some links to quasi-announcements they've made :-). Kito D. Mann Author, JSF in Action www.JSFCentral.com - JSF FAQ, news, and info Thank You, Marty Gainty http://www.laconiadatasystems.com - Original Message - From: "Kito D. Mann" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, October 09, 2003 7:55 PM Subject: Re: JavaServer Faces > Matt, > > This looks like a great taglib -- I wish I had found it when I was working > on some past projects :-). In the JSF world, this would be a component that > you would use the same way -- with a simple taglib. I'm assuming that this > type of functionality is what the highly anticipated JSF "grid" will > provide in the next release of JSF (maybe Craig can extrapolate). There's > an example of a much less capable, but similar, component in JSF EA4. 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. Renderers are separate from the component itself, so > all of the basic properties, like the data source, wouldn't have to be > changed for a new device -- only the renderer. > > Anyway, we're probably getting a little too off-topic, so drop me a line > personally if you want to chat more :-). > > Kito D. Mann > [EMAIL PROTECTED] > Author, JSF in Action > www.JSFCentral.com - JSF FAQ, news, and info > > At 06:37 PM 10/9/2003 -0400, you wrote: > >Here is an example of something I do a lot of w/Struts: > >http://displaytag.sf.net > > > >(that Matt contributed to) > >You can click on examples link (uper right) to see nested, pagination, etc. > > > >Using your skill and experience you listed, can you show something similar? > > > >.V > > > >Kito D. Mann wrote: > >>At 11:20 AM 10/9/2003 -0500, you wrote: > >> > >>>I watched a presentation on JSF last night. Here's my high-level > >>>impressions: > >>> > >>>1. It's a replacement for Struts (no matter what folks say). > >> > >>It may be in the long-term, but it won't be in version 1.0. I think the > >>combination of the two is pretty powerful. > >> > >>>2. It's basically Swing for the Web. > >> > >>True. > >> > >>>3. It's more difficult than Struts. > >> > >>I think it might be more difficult for people who haven't worked with > >>desktop-oriented G
Re: OT FRIDAY: Re: JavaServer Faces
Craig R. McClanahan wrote: And you even forgot JSR-168 too :-) Oh yeah, I did not even criticize that! Next time. ;-} .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT FRIDAY: Re: JavaServer Faces
Vic Cekvenich wrote: Kito D. Mann wrote: 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. 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: > There's an example of a much less capable, but similar, component in JSF EA4. > Kito D. Mann > Author, JSF in Action Vic:... "less capable", and more complex, now that takes a committee to advise me. Craig wrote: >some commenters fail to remember what "early access" means -- it's not done yet. 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): 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. ?? 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]
OT FRIDAY: Re: JavaServer Faces
Kito D. Mann wrote: 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. 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: > There's an example of a much less capable, but similar, component in JSF EA4. > Kito D. Mann > Author, JSF in Action Vic:... "less capable", and more complex, now that takes a committee to advise me. Craig wrote: >some commenters fail to remember what "early access" means -- it's not done yet. 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 Craig wrote (in another thread on EJB): 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. ?? Vic: "HTML tags are a simple way to render input tags" ... simple as in simple is bad? (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. (See, I did not even bring up vendor licensing or Sun's poor finance ;-)) Go Java! KISS, .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
