Still stuck using POH5? Try POH6 - The future of HTML templating in Errai

[Lincoln Baxter, III]

Feedback requested ;)

https://twitter.com/lincolnthree/status/206149646702231552

We are still discussing the names of these annotations, but the basic idea is pretty straightforward. Pure HTML/HTML5 templates come to life simply by referencing data-fields in the template in your @Templated Composite GWT widget.

https://github.com/errai/errai/blob/2.1/errai-cdi/errai-ui/

Cheers,

--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."

[Jason Porter]

How do bind a template to a class?

Sent from my iPhone

[Lincoln Baxter, III]

LoginComponent.java
LoginComponent.html

Or by valuing the annotation.

~Lincoln

[Lincoln Baxter, III]

You can even choose part of a larger template to use for a single component.

[Marius Bogoevici]

On 12-05-25 8:11 PM, Lincoln Baxter, III wrote:

LoginComponent.java
LoginComponent.html

Or by valuing the annotation.

IMO it would be nice to be able to use selectors as part of the value.

[Lincoln Baxter, III]

What do you mean?

[Marius Bogoevici]

On 12-05-26 12:06 AM, Lincoln Baxter, III wrote:

What do you mean?

I was thinking that it could be nice to be able to use CSS selectors to bind components to DOM elements.

[Jason Porter]

Without the annotation member, it's by the name of the file, correct?

Sent from my iPhone

[Jason Porter]

That would be very cool. Perhaps a bit too much rope, but cool. If not the actual components, where the template HTML file should start applying based on data binding. 

Sent from my iPhone

[Lincoln Baxter, III]

Well... it's not really binding... but I see where you are going.

This templating system works by instantiating a single widget for the given Composite component field, then replacing the target Element with the Element of that new widget.

A complication with using CSS selectors is that you introduce a situation for potentially matching on more than one selector.

I think you're going for more of an Aspect-oriented approach, which would be cool, but not really sure I see the use-case there. Could you explain why you would want to use a selector in this way?

~Lincoln

[Lincoln Baxter, III]

Yeah that's right. We need to figure out a nice solution for Extension/Inheritance though.

[Lincoln Baxter, III]

Right now you have to re-apply the annotation and point to the template of the component from which you've extended.

[Jay Balunas]

Hi Lincoln,

This looks interesting, especially for Errai and GWT development models.  Using the data-* properties is an approach more and more frameworks and client developers are using.

Question - you are actually replacing the input element here with a GWT TextBox right?  Not just updating the value of the existing one - right?  

Also, I'm not seeing templating, but widget binding.  I'm assuming you are thinking that you can replace more than just single widget's right?  I.e. the ability to replace whole sets of widgets with one data-binding, by replacing the element marked? 

-----

One frustration I have is taking a jab at POH5.  I think it's a bad idea to use terms like POH6 when we're just starting to push something called POH5.  Think about when people search for POH5, and see POH6.  All this will do is confuse and fragment.  

Especially with the negative connotation from the subject.  Lets not take pot-shots at other teams/projects like this.  As you can see I have no problems with your approach`, and will gladly provide constructive feedback.  

The jab was not needed, or appreciated.  Instead, lets find ways to work together on this type of thing to share the solution with more people.  

-Jay

[Burr Sutter]

We obviously can not use POH6 in the public - just makes us look silly. 

We focus on 3 architectures today:

- JSF + RichFaces

- POH5 via Aerogear

- GWT + Errai 

Lincoln's features falls in the "GWT + Errai" bucket.  

[Lincoln Baxter, III]

Hi folks, Jay, Burr, Aerogear,

I didn't realize that POH5 was a term that we have coined; I thought it was an industry term. My usage of it was only intended as a joke, and I'm sorry for unintentionally slamming part of our group's effort. I didn't mean it that way. In retrospect, I've sent two emails lately (one to Burr and one to this group,) which would have probably set off the same alarms. Please accept my apology.

I've never made it a secret that I think the "pure" HTML/CSS/JS programming model is currently popular because people are waiting for a more well integrated and finished solution, so that is the background of my choice of $subject line. I can't apologize for that because it is certainly how I feel, but that's why we have such lively discussions that move us all forward :)

While I'd argue this point to eternity, please understand that I would never intentionally insult or deride one of our own people or projects; that's simply not me.

Sorry again,
~Lincoln

[Jay Balunas]

On May 30, 2012, at 11:03 AM, Lincoln Baxter, III wrote:

Hi folks, Jay, Burr, Aerogear,

I didn't realize that POH5 was a term that we have coined; I thought it was an industry term. My usage of it was only intended as a joke, and I'm sorry for unintentionally slamming part of our group's effort. I didn't mean it that way. In retrospect, I've sent two emails lately (one to Burr and one to this group,) which would have probably set off the same alarms. Please accept my apology.

Thanks Lincoln, and I do.

I've never made it a secret that I think the "pure" HTML/CSS/JS programming model is currently popular because people are waiting for a more well integrated and finished solution, so that is the background of my choice of $subject line.

I think you'll find a lot of developers that disagree :-)

I can't apologize for that because it is certainly how I feel, but that's why we have such lively discussions that move us all forward :)

+1, not asking you to change your mind, we need differences in opinions.  

[Lincoln Baxter, III]

On Wed, May 30, 2012 at 11:28 AM, Jay Balunas <jbal...@redhat.com> wrote:

On May 30, 2012, at 11:03 AM, Lincoln Baxter, III wrote:

Thanks Lincoln, and I do.

Good, thanks.

I've never made it a secret that I think the "pure" HTML/CSS/JS programming model is currently popular because people are waiting for a more well integrated and finished solution, so that is the background of my choice of $subject line.

I think you'll find a lot of developers that disagree :-)

And that's fine :) What probably best describes my view, to quote Henry Ford is, 'If I'd asked customers what they wanted, they would have said "a faster horse"'

I think this JS/HTML/CSS architecture, with whatever we can build on it, may be difficult to achieve, and it may be a very fast and pretty horse, and we may need that horse very badly, but in the end it'll still be a horse.

[Mike Brock]

Here's some interesting feedback on ErraiU: http://draconianoverlord.com/2012/06/16/errai-ui-initial-impression.html

[Lincoln Baxter, III]

I had replied addressing the "downsides" that he mentioned. Unfortunately the video I posted did not include information about this, but in the end, nothing he mentioned as a concern is actually accurate (my own fault for omission.) But if my comment gets approved, it should show up there, and my next video cast will certainly speak more clearly about the points he raised, because they were good ones.

This was a really good write-up.

~Lincoln

[giov...@atende.info]

I think CSS selectors a great feature. Think in the use case where you have to disable some widget based in some user input.

You want to disable all widget by group. Lets say group a and group b. They are all widgets or dom elements, and have the disable behavior,  but without selector you have to create two lists of widget, reference all widgets by data-field, add every widget on PostConstruct in the list, one by one and create 4 functions to disable/enable the groups a and b. A lot of work boilerplate, and error prone. The is terrific to maintain (you add a widget for the group in the template, and you have to modify the code adding a reference to the widget and them adding on the apropriate list)

If there is another way to do this kind of things in errai ui correct me if I am wrong.

You can see an article about this great flexibity feature of selectors in the java ui framework zkoss: 

http://books.zkoss.org/wiki/Small_Talks/2011/January/Envisage_ZK_6:_An_Annotation_Based_Composer_For_MVC 

[giov...@atende.info]

The other way to implement the behavior I said before is to use javascript, like using the GwtQuery (A jquery wrap)

[Jonathan Fuerth]

Hi Giovanni,

I really like this idea! We've already been talking very seriously about including element ID attributes in the search for injectable fields (so ID and data-field would be equivalent). Why not go all the way and allow CSS selector syntax on the argument to the @DataField annotation? This would be even more flexible if we could inject a collection of Widget or Element classes, like:

  @Inject @DataField("input.expert") List<Widget> expertWidgets;

This would allow us to do things with all the Widgets in the "expert" class as a group. I'm not sure if this specific use case is an ironclad justification for the feature, since it might be best to nest all the "expert" fields inside a panel, and that would provide a grouping in its own.

Maybe this feature becomes more compelling when we think about attaching event handlers:

@EventHandler("expertWidgets")
private void onExpertKeystroke(KeyDownEvent e) {
  ...
}

Let's keep thinking about it. If we can point to a real use case that's not well served by the current setup, this definitely gets my vote!

-Jonathan

--
You received this message because you are subscribed to the Google Groups "JBoss-RWP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jboss-rwp+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[giov...@atende.info]

I agree and I dont know way they use data-field (tedius to write) instead of id. And Why not include css selectors, for me is a very natural way to write and closer to the web specifications.

[Lincoln Baxter, III]

+1

CSS selectors are a natural fit on top of the existing functionality.

data-field is required for several reasons, mostly to create a non-preexisting HTML attribute that does not conflict with any of the above technologies ;)