Re: swing/swt and clay
From: Ryan Wynn [EMAIL PROTECTED] I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? That's an interesting idea. You know, the visual aspect would only be needed in the GUI builder. I wonder if you could create custom components that extended a base GUI component. Create a like component for each JSF component with corresponding properties. The GUI component would only have to hold the values of the properties and represent the composition of the page. The rendering of the component in design mode might be tricky but maybe it could just render an image of the JSF component. What if the GUI components used annotations to associate with a JSF component? On the clay side, we could have a custom handler that would map a jsfid to a swing/swt container. It would only need to instantiate the component to use it's composition to build a JSF tree. The jsfid could be used to override definitions similar to how the HTML mapping works today. Do you think there would be any strange requirements server side to create a swing component but not render it? I believe that swing is not coupled with the OS api but I don't know if the GUI component would require extra resources server side? Ryan Gary
Re: swing/swt and clay
I am pretty sure the GUI designer knows how to draw the widgets based on their ancestry. So, I think if we created subclasses from base Swing components with properties from JSF components then they should up nicely in the designer. I don't think there would be any special req server side to creating swing components without rendering. This is based on the assumption that the components are just javabeans and that they don't have any special plumbing invoked until they are told to draw themselves. Another interesting thing I think is that existing Swing action listeners could possibly be wrapped by Jsf Action listeners which of course would then delegate to the swing listeners. This could be done by the view handler during the translation. On 6/25/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Ryan Wynn [EMAIL PROTECTED] I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? That's an interesting idea. You know, the visual aspect would only be needed in the GUI builder. I wonder if you could create custom components that extended a base GUI component. Create a like component for each JSF component with corresponding properties. The GUI component would only have to hold the values of the properties and represent the composition of the page. The rendering of the component in design mode might be tricky but maybe it could just render an image of the JSF component. What if the GUI components used annotations to associate with a JSF component? On the clay side, we could have a custom handler that would map a jsfid to a swing/swt container. It would only need to instantiate the component to use it's composition to build a JSF tree. The jsfid could be used to override definitions similar to how the HTML mapping works today. Do you think there would be any strange requirements server side to create a swing component but not render it? I believe that swing is not coupled with the OS api but I don't know if the GUI component would require extra resources server side? Ryan Gary
Re: swing/swt and clay
This article seems to be a good starting point. I will play around and see what I can do. http://www.eclipse.org/articles/Article-VE-Custom-Widget/customwidget.html On 6/25/07, Ryan Wynn [EMAIL PROTECTED] wrote: I am pretty sure the GUI designer knows how to draw the widgets based on their ancestry. So, I think if we created subclasses from base Swing components with properties from JSF components then they should up nicely in the designer. I don't think there would be any special req server side to creating swing components without rendering. This is based on the assumption that the components are just javabeans and that they don't have any special plumbing invoked until they are told to draw themselves. Another interesting thing I think is that existing Swing action listeners could possibly be wrapped by Jsf Action listeners which of course would then delegate to the swing listeners. This could be done by the view handler during the translation. On 6/25/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Ryan Wynn [EMAIL PROTECTED] I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? That's an interesting idea. You know, the visual aspect would only be needed in the GUI builder. I wonder if you could create custom components that extended a base GUI component. Create a like component for each JSF component with corresponding properties. The GUI component would only have to hold the values of the properties and represent the composition of the page. The rendering of the component in design mode might be tricky but maybe it could just render an image of the JSF component. What if the GUI components used annotations to associate with a JSF component? On the clay side, we could have a custom handler that would map a jsfid to a swing/swt container. It would only need to instantiate the component to use it's composition to build a JSF tree. The jsfid could be used to override definitions similar to how the HTML mapping works today. Do you think there would be any strange requirements server side to create a swing component but not render it? I believe that swing is not coupled with the OS api but I don't know if the GUI component would require extra resources server side? Ryan Gary
Re: swing/swt and clay
Hi Ryan, I am not sure exactly what you want or heading to, but if the question is that is there a visual environtment to drag and drop components or widgets then you might wanna look into clay plug-in for eclipse which I believe it is in development. Ryan Wynn [EMAIL PROTECTED] wrote: I am pretty sure the GUI designer knows how to draw the widgets based on their ancestry. So, I think if we created subclasses from base Swing components with properties from JSF components then they should up nicely in the designer. I don't think there would be any special req server side to creating swing components without rendering. This is based on the assumption that the components are just javabeans and that they don't have any special plumbing invoked until they are told to draw themselves. Another interesting thing I think is that existing Swing action listeners could possibly be wrapped by Jsf Action listeners which of course would then delegate to the swing listeners. This could be done by the view handler during the translation. On 6/25/07, Gary VanMatre wrote: From: Ryan Wynn I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? That's an interesting idea. You know, the visual aspect would only be needed in the GUI builder. I wonder if you could create custom components that extended a base GUI component. Create a like component for each JSF component with corresponding properties. The GUI component would only have to hold the values of the properties and represent the composition of the page. The rendering of the component in design mode might be tricky but maybe it could just render an image of the JSF component. What if the GUI components used annotations to associate with a JSF component? On the clay side, we could have a custom handler that would map a jsfid to a swing/swt container. It would only need to instantiate the component to use it's composition to build a JSF tree. The jsfid could be used to override definitions similar to how the HTML mapping works today. Do you think there would be any strange requirements server side to create a swing component but not render it? I believe that swing is not coupled with the OS api but I don't know if the GUI component would require extra resources server side? Ryan Gary - Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
Re: swing/swt and clay
Hi Ryan, I am not sure exactly what you want or heading to, but if the question is that is there a visual environtment to drag and drop components or widgets then you might wanna look into clay plug-in for eclipse which I believe it is in development. This is actually the same Ryan who donated the clay eclipse plugin (we are waiting for apache legal to verify the artifacts - Ryan's thinking out of the box again :--)
Re: swing/swt and clay
From: Craig McClanahan [EMAIL PROTECTED] On 6/23/07, Ryan Wynn wrote: I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. I can throw in a couple of thoughts based on our (Sun's) experience with WYSIWIG editing for JSF views in Java Studio Creator and Visual Web Pack. * The design surface we used started life (many years ago) as a very hacked version of the Swing HTML 3.2 widget, and nowadays looks nothing at all like that code. * The hard part about rendering JSF components isn't really the widget itself ... it's the fact that any reasonable JSF component is also going to assume that CSS can be used. Emulating all of *that* is not an easy task, no matter how you approach it. (We do a fairly large percentage of CSS 2, but there's tons of edge cases -- to say nothing of the fact that you need to decide which browser's incompatible behavior you should emulate for lots of these settings.) * To say nothing of the fact that, besides support for CSS, your typical JSF component today is probably also going to assume that JavaScript and DHTML are also available, so you can build user interfaces for Ajax enabled applications. If you are not looking to build a tool that would work for all design needs, I think that the MyFaces Trinidad components are an interesting option for enterprise developers. They have a predefined css skins that apply application wide. The java script and PPR is built into the library. You really don't even need markup. There is a component for everything. The Infragistics smart client components are very popular amongst the dark-side and have the same skinning idea [1]. [1] http://www.infragistics.com/dotnet/netadvantage/winforms.aspx#Overview * Creating Swing components that take CSS, DHTML, and JavaScript into account is, I suppose, technically feasible ... but by then you've written a pretty large portion of a web browser :-). It's hard to believe that you can get these IDE's for free now. Java Rocks! * Expecting JSF component authors to write Swing component analogs for all their components doesn't seem like something the market would accept very well. No doubt, even selling JSP tags for this purpose Craig There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? Ryan
