Re: UIBinder Benefits?
Hi, * a further language. No way to debug it FALSE: xml is not a new language, there is an XSD, there is also a eclipse editor with auto complete and inline problem highlighting to work with your own ui.xml template. XML is rather structure of a language. When you consider this as a language, englisch, german, french, russian, italian needs to consider be the same language because the have the same structure. They do building words with characters from an alphabet. This is different from corean or chinese. * limited to a set of widgets FALSE: the only requirement to attach a widget in a ui.xml is that it is a widget. I checked this again and you are right. I missed that the namespace is assigned to a package. Probably comes from using the namespace for non widget (g:north for example) Beside, I still do not see, how own container analog to DockLayoutPanel can be setup. However, this is neither a focus of my generator approach. With this aspect my generator approach and UiBinder are nearly the same My generator approach is still a little bit better. Rename your widget in eclipse. Eclipse also change the class name in the definition interface, UiBinder produces errors. Or rename UiBinder.ui.xml, the class isn't renamed, producing errors. * it is a graphic designer mindset (we do this app, the app is our concern) not a developer mindset (we do this class of apps, we separate concerns) *TRUE: and this is actually a very good thing for several reasons This depends how many application you are going to do with GWT. When you are going to build multiple application, topics like reusability, consistency and separation of concerns become important. graphic design in general do not consider such aspects (there are exception from the rule) * no clear separation, no SoC. A big bunch of widgets and css-styles. *FALSE: You're java code does not contain layout or styling. There is SoC, you can manipulate rebuild your look and feel, layout, style without touching the java code. Separation of Look and Feel is just one level of SoC. And UiBuilder mixes up structure and layout. This is the opposite of SoC. To separate further is not possible, dead end as I have shown it. * no separation of theme/skin *FALSE: you can switch the (ui.xml) template file a new UiBinder per theme? graphic designer mind set? This is a good as to write a new application per theme. Achieving reuse is a major goal for developers. or CssResource several ways, and you can always load @external styles in the css/ui.xml or programatically set/implement them. Maybe you should explain this in a separate thread. To have a use case, please show how you would change color, font and padding at a central place outside UiBinder but with impact to UiBinder. Hope that's the factual information you were looking for :) Yes, there was some. But what about the following generator: layout automatically according css-style and annotations UiBinder: dialog designer does it manually. generator: i18n constant change at any time UiBinder: i18n per compilation generator: automatic labeling, yes UiBinder: automatic labeling, no generator: consistent layout is automatically asured UiBinder: layout by accident/capability of the designer Stefan Bachert http://gwtworld.de On Wed, Jun 23, 2010 at 11:45 PM, Stefan Bachert stefanbach...@yahoo.dewrote: Hi, On Jun 22, 3:36 pm, Andrew Hughes ahhug...@gmail.com wrote: Almost all of the problem's listed below are bad advice and I suggest you disregard them. Do you, or others, have any valid arguments (opinions are no valid arguments) I am not going to do things the wrong or the poor way just because most people are doing so. The main problem I have with UiBinder is that when you try and use it with the MVP architecture best practice, you have to boilerplate all the parent/child (view) widget's. Which means you'll see a lot of. I am explaining the long story about my lessons I learned. The problem with any pure declarative language is that you reached the dead end of separation. Either a dedicated aspect of separation is build in, or you are lost. There is always a tradeof where declarative languages will become more complex than an imperative one. UiBuilder is a pure declarative language. Let us look at CSS as a simple pure declarative language for example. Consider there are two aspects/concern defining an value. aspect 1) general theming. you want a certain padding aspect 2) behaviour, you want to simulate a pressed state. Therefore you need to change padding depending on the state With a imperative language (java) you would just combine/add both aspects. With a language like css either this is supported or not. In css it is not, bad luck. (CSS3 supports a little imperativity with calc, but only FF is supporting this somehow) And the pure declarative language CSS 2.1 still fails to
Re: UIBinder Benefits?
Hi Sri, rewind where the discussion starts from readability: I state java is much more readable the xml. readablity improves understanding. Could you agree with me? debuggability the understanding of a declarative language depends totally on the documentation (We all know that document might missing, wrong, incomplete, misleading, oh, yes sometimes it is even correct ;-) while for an imperative language debugging is a further way to get insights, to see what is going on. debuggability improves understanding. Could you agree with me? The most important advantage of the generator approach is, to be able to drive more generators, or extend the existing one. Capabilities with generator approach * rules are in the generator, one place * control combined widgets (text + label for example making both enable/disable/hidden) * input is usable for further code generation Ideas * generate controller code, too (input DialogInterface and an interface defining a domain/app/session object) * generate request code, too * generate client cache code, too * ... I do see no way to use UiBinder for that. Do you have an idea how to generate such things using the UiBinder definition? Stefan Bachert http://gwtworld.de On Jun 24, 10:57 pm, Sripathi Krishnan sripathi.krish...@gmail.com wrote: Lets try to discuss the statement XML is declarative, and therefore not debuggable. UIBinder uses XML, and therefore, is not debuggable. Totally agree on the first part of the statement - XML is a mess if you put logic into it. But, here is the key point - you cannot put logic in *.ui.xml even if you wanted to. There just isn't any way to do so. If you have seen the design notes, the GWT does not/will not ever allow things like if statements and while loops into *.ui.xml. The logic of your application stays 100% in java code, and is 100% debuggable. Lets pursue debugging in java a bit more. Say you have this fragment in *.ui.xml g:HTMLPaneldiv class=newsGood News! Click the button/divg:Button ui:field=clickMe//g:HTMLPanel Assume that you wrote the equivalent java code for that. Now you are testing, and you see the text is not appearing in red color as it should. Tell me, how will you debug that in Eclipse? You can't - its a UI issue, and you have to mess with tools like firebug to figure out why the particular css class does not apply. UIBinder is no new language. In fact, it isn't a programming language at all. Think of it is an intelligent way to externalize your html markup and css. --Sri On 24 June 2010 23:45, Stefan Bachert stefanbach...@yahoo.de wrote: On Jun 23, 7:49 pm, Blessed Geek blessedg...@gmail.com wrote: Looking at your annotation, I find that I have to learn yet another language. Annotation are regular java. And UiBinder is using annotations, too. I mean learning the annotation style as a language. UiBinder is in XML and if you are familiar with XML, it's a breeze to understand what's going on. You missed the point. XML is a totally different language than java and it is not debuggable because pure declarative. Java is much more user readable than XML. For the many many years doing distributed computing in industrial environment ... You are going off topic, and you are not debating in honest way. Once these two issues are settled - hmmm ... there seems to be no bounds to what my enthusiasm could do with UiBinder. Ok, you won't be able to use your gui definition to generate more programming artefacts. You seems to feel well in the dead end, your choice. I do not intend to live in the dead end, my choice. Stefan Bachert http://gwtworld.de -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
On Fri, Jun 25, 2010 at 7:28 PM, Stefan Bachert stefanbach...@yahoo.dewrote: Hi Sri, rewind where the discussion starts from readability: I state java is much more readable the xml. readablity improves understanding. Could you agree with me? Not when it comes to designing UI. To be honest, such claim almost sounds funny to me. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
On Jun 23, 7:49 pm, Blessed Geek blessedg...@gmail.com wrote: Looking at your annotation, I find that I have to learn yet another language. Annotation are regular java. And UiBinder is using annotations, too. I mean learning the annotation style as a language. UiBinder is in XML and if you are familiar with XML, it's a breeze to understand what's going on. You missed the point. XML is a totally different language than java and it is not debuggable because pure declarative. Java is much more user readable than XML. For the many many years doing distributed computing in industrial environment ... You are going off topic, and you are not debating in honest way. Once these two issues are settled - hmmm ... there seems to be no bounds to what my enthusiasm could do with UiBinder. Ok, you won't be able to use your gui definition to generate more programming artefacts. You seems to feel well in the dead end, your choice. I do not intend to live in the dead end, my choice. Stefan Bachert http://gwtworld.de -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
Lets try to discuss the statement XML is declarative, and therefore not debuggable. UIBinder uses XML, and therefore, is not debuggable. Totally agree on the first part of the statement - XML is a mess if you put logic into it. But, here is the key point - you cannot put logic in *.ui.xml even if you wanted to. There just isn't any way to do so. If you have seen the design notes, the GWT does not/will not ever allow things like if statements and while loops into *.ui.xml. The logic of your application stays 100% in java code, and is 100% debuggable. Lets pursue debugging in java a bit more. Say you have this fragment in *.ui.xml g:HTMLPaneldiv class=newsGood News! Click the button/divg:Button ui:field=clickMe//g:HTMLPanel Assume that you wrote the equivalent java code for that. Now you are testing, and you see the text is not appearing in red color as it should. Tell me, how will you debug that in Eclipse? You can't - its a UI issue, and you have to mess with tools like firebug to figure out why the particular css class does not apply. UIBinder is no new language. In fact, it isn't a programming language at all. Think of it is an intelligent way to externalize your html markup and css. --Sri On 24 June 2010 23:45, Stefan Bachert stefanbach...@yahoo.de wrote: On Jun 23, 7:49 pm, Blessed Geek blessedg...@gmail.com wrote: Looking at your annotation, I find that I have to learn yet another language. Annotation are regular java. And UiBinder is using annotations, too. I mean learning the annotation style as a language. UiBinder is in XML and if you are familiar with XML, it's a breeze to understand what's going on. You missed the point. XML is a totally different language than java and it is not debuggable because pure declarative. Java is much more user readable than XML. For the many many years doing distributed computing in industrial environment ... You are going off topic, and you are not debating in honest way. Once these two issues are settled - hmmm ... there seems to be no bounds to what my enthusiasm could do with UiBinder. Ok, you won't be able to use your gui definition to generate more programming artefacts. You seems to feel well in the dead end, your choice. I do not intend to live in the dead end, my choice. Stefan Bachert http://gwtworld.de -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
There's some good doco on this on the GWT site * a further language. No way to debug it FALSE: xml is not a new language, there is an XSD, there is also a eclipse editor with auto complete and inline problem highlighting to work with your own ui.xml template. * limited to a set of widgets FALSE: the only requirement to attach a widget in a ui.xml is that it is a widget. * it is a graphic designer mindset (we do this app, the app is our concern) not a developer mindset (we do this class of apps, we separate concerns) *TRUE: and this is actually a very good thing for several reasons * no clear separation, no SoC. A big bunch of widgets and css-styles. *FALSE: You're java code does not contain layout or styling. There is SoC, you can manipulate rebuild your look and feel, layout, style without touching the java code. * no separation of theme/skin *FALSE: you can switch the (ui.xml) template file or CssResource several ways, and you can always load @external styles in the css/ui.xml or programatically set/implement them. Hope that's the factual information you were looking for :) On Wed, Jun 23, 2010 at 11:45 PM, Stefan Bachert stefanbach...@yahoo.dewrote: Hi, On Jun 22, 3:36 pm, Andrew Hughes ahhug...@gmail.com wrote: Almost all of the problem's listed below are bad advice and I suggest you disregard them. Do you, or others, have any valid arguments (opinions are no valid arguments) I am not going to do things the wrong or the poor way just because most people are doing so. The main problem I have with UiBinder is that when you try and use it with the MVP architecture best practice, you have to boilerplate all the parent/child (view) widget's. Which means you'll see a lot of. I am explaining the long story about my lessons I learned. The problem with any pure declarative language is that you reached the dead end of separation. Either a dedicated aspect of separation is build in, or you are lost. There is always a tradeof where declarative languages will become more complex than an imperative one. UiBuilder is a pure declarative language. Let us look at CSS as a simple pure declarative language for example. Consider there are two aspects/concern defining an value. aspect 1) general theming. you want a certain padding aspect 2) behaviour, you want to simulate a pressed state. Therefore you need to change padding depending on the state With a imperative language (java) you would just combine/add both aspects. With a language like css either this is supported or not. In css it is not, bad luck. (CSS3 supports a little imperativity with calc, but only FF is supporting this somehow) And the pure declarative language CSS 2.1 still fails to support some simpliest common needs. Remember all the time the topic of centering widget is coming up. UiBinder fails the same way. It limits always your capabilities as a developer. Either a concept is explicitly supported, or you are lost. There are other ways to be more declarative. One way is to use fluent interfaces. Than you use both declarative and imperative approaches, and can switched to the one which is more appropriate the way I am currently using is to define interfaces and use generators. The input looks like the interfaces at the end of this mail. It defines a dialog with 2 subdialog. To create you need just. LogonDialog logon = GWT.create(LogonDialog.class); .. logon.layout(); logon.setI18N (..Constants); Accessing is a easy as String text = logon.eingabe.eMail().getText() Let us compare this approach with UiBinder generator: only one annotated interface for deferred binding UiBinder: class and UiBinder.XML with XMTL, CSS and WidgetsTags generator: layout automatically according css-style and annotations UiBinder: dialog designer does it manually. generator: i18n constant change at any time UiBinder: i18n per compilation generator: automatic labeling, yes UiBinder: automatic labeling, no generator: styles based theming UiBinder: styles based on accident generator: widgets, any with a default constructor UiBinder: some widgets generator: consistent layout is automatically asured UiBinder: layout by accident/capability of the designer generator: debugging: yes, pure java UiBinder: no chance Open questions with UiBinder * how to deal when the themes * how to use it a input for further code generation (I think no way) Capabilities with generator approach * rules are in the generator, one place * control combined widgets (text + label for example making both enable/disable/hidden) * input is usable for further code generation Ideas * generate controller code, too (input DialogInterface and an interface defining a domain/app/session object) * generate request code, too * generate client cache code, too * ... UiBinder is for the one how like to stay in a death end. When you want to generate boiler plate code, you need to get rid
Re: UIBinder Benefits?
On Jun 24, 11:15 am, Stefan Bachert stefanbach...@yahoo.de wrote: You are going off topic, and you are not debating in honest way. Nope, never meant to debate but simply to relate why I am dishonestly, mysteriously, inexplicably biased towards XML. You are looking to win a debate, I see. Sorry, you win the debate. I concede. I wasn't debating but attempting to persuade why you too might need to engage in being familiar with dishonest use of XML. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
Hi,
On Jun 22, 3:36 pm, Andrew Hughes ahhug...@gmail.com wrote:
Almost all of the problem's listed below are bad advice and I suggest you
disregard them.
Do you, or others, have any valid arguments (opinions are no valid
arguments)
I am not going to do things the wrong or the poor way just because
most people are doing so.
The main problem I have with UiBinder is that when you try and use it with
the MVP architecture best practice, you have to boilerplate all the
parent/child (view) widget's. Which means you'll see a lot of.
I am explaining the long story about my lessons I learned.
The problem with any pure declarative language is that you reached the
dead end of separation.
Either a dedicated aspect of separation is build in, or you are lost.
There is always a tradeof where declarative languages will become more
complex than an imperative one.
UiBuilder is a pure declarative language.
Let us look at CSS as a simple pure declarative language for example.
Consider there are two aspects/concern defining an value.
aspect 1) general theming. you want a certain padding
aspect 2) behaviour, you want to simulate a pressed state. Therefore
you need to change padding depending on the state
With a imperative language (java) you would just combine/add both
aspects.
With a language like css either this is supported or not. In css it is
not, bad luck.
(CSS3 supports a little imperativity with calc, but only FF is
supporting this somehow)
And the pure declarative language CSS 2.1 still fails to support some
simpliest common needs.
Remember all the time the topic of centering widget is coming up.
UiBinder fails the same way. It limits always your capabilities as a
developer. Either a concept is explicitly supported, or you are lost.
There are other ways to be more declarative. One way is to use fluent
interfaces. Than you use both declarative and imperative approaches,
and can switched to the one which is more appropriate
the way I am currently using is to define interfaces and use
generators.
The input looks like the interfaces at the end of this mail.
It defines a dialog with 2 subdialog.
To create you need just.
LogonDialog logon = GWT.create(LogonDialog.class);
..
logon.layout();
logon.setI18N (..Constants);
Accessing is a easy as
String text = logon.eingabe.eMail().getText()
Let us compare this approach with UiBinder
generator: only one annotated interface for deferred binding
UiBinder: class and UiBinder.XML with XMTL, CSS and WidgetsTags
generator: layout automatically according css-style and annotations
UiBinder: dialog designer does it manually.
generator: i18n constant change at any time
UiBinder: i18n per compilation
generator: automatic labeling, yes
UiBinder: automatic labeling, no
generator: styles based theming
UiBinder: styles based on accident
generator: widgets, any with a default constructor
UiBinder: some widgets
generator: consistent layout is automatically asured
UiBinder: layout by accident/capability of the designer
generator: debugging: yes, pure java
UiBinder: no chance
Open questions with UiBinder
* how to deal when the themes
* how to use it a input for further code generation (I think no way)
Capabilities with generator approach
* rules are in the generator, one place
* control combined widgets (text + label for example making both
enable/disable/hidden)
* input is usable for further code generation
Ideas
* generate controller code, too (input DialogInterface and an
interface defining a domain/app/session object)
* generate request code, too
* generate client cache code, too
* ...
UiBinder is for the one how like to stay in a death end.
When you want to generate boiler plate code,
you need to get rid of UiBinder.
Stefan Bachert
http://gwtworld.de
-
@SpaceStyle(a1-DialogSpace)
public interface LogonDialog extends DialogInterface {
@OnlyI18N
static interface Eingabe extends DialogInterface {
@Label(eMail)
@NewLine()
public TextBox eMail ();
@Label(kennwort)
@NewLine()
public PasswordTextBox kennwort ();
@Label(kennwortWiederholung)
@NewLine()
public PasswordTextBox kennwortWiederholung ();
public void setI18N (Lokalisierung pI18N);
}
@OnlyI18N
@SpaceStyle(a1-ButtonSpace)
static interface Schaltflaeche extends DialogInterface {
@Text(anmelden)
@NewLine(LineBreak.BREAKEND)
public Button anmelden ();
@Text(kennwortVergessen)
@NewLine(LineBreak.BREAKEND)
public Button kennwortVergessen ();
@Text(registrieren)
@NewLine(LineBreak.BREAKEND)
public Button registrieren ();
public void setI18N (Lokalisierung pI18N);
}
@Placement(horizontal=Alignment.GROW)
public Eingabe eingabe ();
@NewLine (LineBreak.BREAKEND)
public Schaltflaeche schaltflaechen ();
Re: UIBinder Benefits?
Looking at your annotation, I find that I have to learn yet another language. I mean learning the annotation style as a language. UiBinder is in XML and if you are familiar with XML, it's a breeze to understand what's going on. For the many many years doing distributed computing in industrial environment - I find the unfortunate situation that data come in many formats. There are log sheets that each vendor equipment invented with their own respective formats. Frequently, the same equipment maker willy-nilly comes out with a slight variation just because they have a new line of models. Some are text, some are XML. if you do not strive to be familiar with XML, you don't get to work. So, every time I need to write a data loader for a piece of equipment, should I have complained to management - I have to learn another language, sir/maam? Moreover, databases I encountered are of differing schemata of course. Getting familiarized with an XML schema is similar to encountering yet another database schema. I am personally guilty of inventing more database and XML schemata (the plural for schema is schemata, http://h2g2java.blessedgeek.com/2010/03/data-is-already-plural.html) and adding to the plethora of new languages people who worked with me had to learn. For those of us who've had the misfortune of having to frequently work with deciphering new XML and database schemata, which in your sense - frequently having to learn new languages, UiBinder comes as natural as mother tongue. So my condolences that you find UiBinder difficult for you due to your less exposure to XML. It is indeed an unfortunate situation that the people who came out with UiBinder did not take into consideration that not all people are familiar with XML or are resonant to data schemata. After all, UiBinder inventors probably made a high presumption that every and any one using GWT has an industrial purpose to using it. Fortunately for me, and to your undue inconvenience (my apologies again), there must be a lot of programmers out there who are like- minded with me about the convenience of UiBinder due to our inexplicable and mysterious bias towards XML. I think it is safe for me to say that I am representative of those appreciative of UiBinder - that our tacit complain are the following mysteries: Having invented such a wonderous framework, - why did the UiBinder inventors forgot about the need to provide a means to register custorm parsers? - why did they not realise the extreme inconvenience of not being able extend Uibinderable classes properly? Once these two issues are settled - hmmm ... there seems to be no bounds to what my enthusiasm could do with UiBinder. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
Great post! Jocke 2010/6/23 Blessed Geek blessedg...@gmail.com Looking at your annotation, I find that I have to learn yet another language. I mean learning the annotation style as a language. UiBinder is in XML and if you are familiar with XML, it's a breeze to understand what's going on. For the many many years doing distributed computing in industrial environment - I find the unfortunate situation that data come in many formats. There are log sheets that each vendor equipment invented with their own respective formats. Frequently, the same equipment maker willy-nilly comes out with a slight variation just because they have a new line of models. Some are text, some are XML. if you do not strive to be familiar with XML, you don't get to work. So, every time I need to write a data loader for a piece of equipment, should I have complained to management - I have to learn another language, sir/maam? Moreover, databases I encountered are of differing schemata of course. Getting familiarized with an XML schema is similar to encountering yet another database schema. I am personally guilty of inventing more database and XML schemata (the plural for schema is schemata, http://h2g2java.blessedgeek.com/2010/03/data-is-already-plural.html) and adding to the plethora of new languages people who worked with me had to learn. For those of us who've had the misfortune of having to frequently work with deciphering new XML and database schemata, which in your sense - frequently having to learn new languages, UiBinder comes as natural as mother tongue. So my condolences that you find UiBinder difficult for you due to your less exposure to XML. It is indeed an unfortunate situation that the people who came out with UiBinder did not take into consideration that not all people are familiar with XML or are resonant to data schemata. After all, UiBinder inventors probably made a high presumption that every and any one using GWT has an industrial purpose to using it. Fortunately for me, and to your undue inconvenience (my apologies again), there must be a lot of programmers out there who are like- minded with me about the convenience of UiBinder due to our inexplicable and mysterious bias towards XML. I think it is safe for me to say that I am representative of those appreciative of UiBinder - that our tacit complain are the following mysteries: Having invented such a wonderous framework, - why did the UiBinder inventors forgot about the need to provide a means to register custorm parsers? - why did they not realise the extreme inconvenience of not being able extend Uibinderable classes properly? Once these two issues are settled - hmmm ... there seems to be no bounds to what my enthusiasm could do with UiBinder. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
That has to be the most disturbing use of annotations I have ever seen... on so many levels... On Wed, Jun 23, 2010 at 11:52 AM, jocke eriksson jock...@gmail.com wrote: Great post! Jocke 2010/6/23 Blessed Geek blessedg...@gmail.com Looking at your annotation, I find that I have to learn yet another language. I mean learning the annotation style as a language. UiBinder is in XML and if you are familiar with XML, it's a breeze to understand what's going on. For the many many years doing distributed computing in industrial environment - I find the unfortunate situation that data come in many formats. There are log sheets that each vendor equipment invented with their own respective formats. Frequently, the same equipment maker willy-nilly comes out with a slight variation just because they have a new line of models. Some are text, some are XML. if you do not strive to be familiar with XML, you don't get to work. So, every time I need to write a data loader for a piece of equipment, should I have complained to management - I have to learn another language, sir/maam? Moreover, databases I encountered are of differing schemata of course. Getting familiarized with an XML schema is similar to encountering yet another database schema. I am personally guilty of inventing more database and XML schemata (the plural for schema is schemata, http://h2g2java.blessedgeek.com/2010/03/data-is-already-plural.html) and adding to the plethora of new languages people who worked with me had to learn. For those of us who've had the misfortune of having to frequently work with deciphering new XML and database schemata, which in your sense - frequently having to learn new languages, UiBinder comes as natural as mother tongue. So my condolences that you find UiBinder difficult for you due to your less exposure to XML. It is indeed an unfortunate situation that the people who came out with UiBinder did not take into consideration that not all people are familiar with XML or are resonant to data schemata. After all, UiBinder inventors probably made a high presumption that every and any one using GWT has an industrial purpose to using it. Fortunately for me, and to your undue inconvenience (my apologies again), there must be a lot of programmers out there who are like- minded with me about the convenience of UiBinder due to our inexplicable and mysterious bias towards XML. I think it is safe for me to say that I am representative of those appreciative of UiBinder - that our tacit complain are the following mysteries: Having invented such a wonderous framework, - why did the UiBinder inventors forgot about the need to provide a means to register custorm parsers? - why did they not realise the extreme inconvenience of not being able extend Uibinderable classes properly? Once these two issues are settled - hmmm ... there seems to be no bounds to what my enthusiasm could do with UiBinder. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
Almost all of the problem's listed below are bad advice and I suggest you disregard them. Except for the it's a graphic designer mindset - this statement is correct. Thankfully we no longer need to code our layout and style in java! The main problem I have with UiBinder is that when you try and use it with the MVP architecture best practice, you have to boilerplate all the parent/child (view) widget's. Which means you'll see a lot of. @UiField(provided=true) You then need to programatically decide/code when the uibinder should be called. I would still recommend it. On Mon, Jun 21, 2010 at 11:47 PM, Stefan Bachert stefanbach...@yahoo.dewrote: Hi, I don't use UiBinder in general. It may be nice for some hacks. UiBinder has a lot of problems * a further language. No way to debug it * limited to a set of widgets * it is a graphic designer mindset (we do this app, the app is our concern) not a developer mindset (we do this class of apps, we separate concerns) * no clear separation, no SoC. A big bunch of widgets and css-styles. * no separation of theme/skin When you watch the video with Ray Rian (gwt wave, discussion) you clearly read between the lines that he doesn't like UiBinder, too. The only advantage I see, it is faster to create a fragment of HTML code than to build it via java/javascript code. But how often you will create a html-structure? In a good design this will rarely happen. And performance is one but the only design goal. Stefan Bachert http://gwtworld.de On Jun 21, 3:23 am, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
Beside of how easier its to write layouts in xml instead of java and the fact that you can easily embed css, images and other resources, if you use uiBinder with HTMLPanel you will get the best effortless performance with gwt. 2010/6/20 spierce7 spier...@gmail.com thanks :-) On Jun 20, 9:39 pm, Jaroslav Záruba jaroslav.zar...@gmail.com wrote: http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html I think you will have idea of the benefits once you start reading that. :) On Mon, Jun 21, 2010 at 3:23 AM, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
Hi, I don't use UiBinder in general. It may be nice for some hacks. UiBinder has a lot of problems * a further language. No way to debug it * limited to a set of widgets * it is a graphic designer mindset (we do this app, the app is our concern) not a developer mindset (we do this class of apps, we separate concerns) * no clear separation, no SoC. A big bunch of widgets and css-styles. * no separation of theme/skin When you watch the video with Ray Rian (gwt wave, discussion) you clearly read between the lines that he doesn't like UiBinder, too. The only advantage I see, it is faster to create a fragment of HTML code than to build it via java/javascript code. But how often you will create a html-structure? In a good design this will rarely happen. And performance is one but the only design goal. Stefan Bachert http://gwtworld.de On Jun 21, 3:23 am, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
I think I disagree with you on almost all points. I have been using UIBinder much before GWT2.0 was officially released, and I think to use GWT straight-from-trunk to leverage UIBinder was the best architectural decision we made. a further language. No way to debug it Its the language of the web. If you are building websites, you ought to know html. There is no escaping that fact. And because it is HTML, debugging layout problems is just a matter of pulling out tools like firebug and the like. limited to a set of widgets .. but you are free to develop and use your own widgets. Besides, you have the full power of HTML. And, when it comes to widgets, its GWT in general which is poor; it has nothing to do with UiBinder. I mean, there are only 4-5 widgets that are supported by GWT but not by UIBinder. it is a graphic designer mindset (we do this app, the app is our concern) not a developer mindset (we do this class of apps, we separate concerns). no clear separation, no SoC. A big bunch of widgets and css-styles. It actually is the best possible separation of concerns. Graphic designer works on the *.ui.xml - its just html, so he doesn't need to learn anything new. The developer works on the corresponding *.java file - he doesn't care about the layout or styling information. Both teams make changes almost independently, and its best utilization of each teams skills. When you watch the video with Ray Rian (gwt wave, discussion) you clearly read between the lines that he doesn't like UiBinder, too. Er, no. I certainly didn't read such a message. But how often you will create a html-structure? In a good design this will rarely happen. I find myself creating or changing HTML a lot frequently than changing the logic. Again, as I said, you are building for the browser, and there just isn't a way to escape HTML. Embrace html, and you will surely be a lot more productive. And performance is one but not the only design goal. Agree that performance is not the only goal. But when you make a web-application (think gmail) that will not be refreshed/reloaded for long time periods, you cannot afford to perform DOM manipulations all the time. innerHTML is order of magnitudes faster than corresponding dom insertions.. --Sri On 21 June 2010 19:47, Stefan Bachert stefanbach...@yahoo.de wrote: Hi, I don't use UiBinder in general. It may be nice for some hacks. UiBinder has a lot of problems * a further language. No way to debug it * limited to a set of widgets * it is a graphic designer mindset (we do this app, the app is our concern) not a developer mindset (we do this class of apps, we separate concerns) * no clear separation, no SoC. A big bunch of widgets and css-styles. * no separation of theme/skin When you watch the video with Ray Rian (gwt wave, discussion) you clearly read between the lines that he doesn't like UiBinder, too. The only advantage I see, it is faster to create a fragment of HTML code than to build it via java/javascript code. But how often you will create a html-structure? In a good design this will rarely happen. And performance is one but the only design goal. Stefan Bachert http://gwtworld.de On Jun 21, 3:23 am, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. I think the decision to build from gwt trunk was the best architectural decision we took -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
uibinder separate layout out of your ui. pre uibinder we would use inner class to create hierarchy like structure for layout right inside java! That kind of code would look bit messy and unstructured to some one who is not familiar with the style of programming. As a developer, I would like to keep complete control with me and avoid more moving parts, especially non debug-able xml code! But in a way your java code looks much cleaner with uibinder. Since uibinder is responsible only for laying out your components, it nicely separates itself from the corresponding java class. Once you get used to it, you start liking it. When uibinder was introduced, I was hesitant myself but now I have adopted it. In fact I am craving for better support of some panels and widgets. Gwt programming is such that in most cases(unless you go out of the way) you end of creating not more than one or 2 pages of ui.xml files. hence uibinder files are very readable and usable! Infact my question is, why xml? why not yaml or json? Rakesh Wagh On Jun 20, 6:23 pm, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
On Mon, Jun 21, 2010 at 9:43 PM, rakesh wagh rake...@gmail.com wrote: Infact my question is, why xml? why not yaml or json? Because HTML is de-facto XML? And given UiBinder is mix of HTML + the UI-definition the choice has been obvious, IMO. Not speaking of data-structure definition, format validation, transformations - i.e. overall support. I don't really see single reason for using anything else. Rakesh Wagh On Jun 20, 6:23 pm, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html I think you will have idea of the benefits once you start reading that. :) On Mon, Jun 21, 2010 at 3:23 AM, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: UIBinder Benefits?
thanks :-) On Jun 20, 9:39 pm, Jaroslav Záruba jaroslav.zar...@gmail.com wrote: http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html I think you will have idea of the benefits once you start reading that. :) On Mon, Jun 21, 2010 at 3:23 AM, spierce7 spier...@gmail.com wrote: Does using the UI Binder provide any benefits? I watched some of the I/ O conference, and it seemed like they made reference that the UI Binder using the browsers native rendering engine (or something like that), and it being a lot faster, but they didn't really specify whether that was the layout panels, or using the ui binder. What are the benefits to using the UIBinder, and where can I learn to use it? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
