Re: HTML5: data-* atrributes
It so appears but not quite.
The serverside will repeat the html fragment that is provided by the web
designer.
The easiest to illustrate this is with is a list: .
The designer provides the html that is the true template for the data. All
that the serverside needs to do is repeat the as formatted. The
following is the logical flow:
HtmlList hList = renderedPage.getElement("myListId");
List items = db.getItems();
foreach (item: items) {
hList.add(item);
}
So, the serverside does not really build the html but repeats the html
provided. In this case, no component will ever have it's own html embedded
as it is the case in most frameworks.
In the case that there is text needs to be repeated in each , the
designer will provided inside the as such: Item span id="someId"
The ultimate goal is that the html code is never hidden in java code.
--
View this message in context:
http://click.1134972.n2.nabble.com/HTML5-data-atrributes-tp5583298p5593298.html
Sent from the click-development mailing list archive at Nabble.com.
Re: HTML5: data-* atrributes
This one > > > > Name tag color: > or $table >Not only so, but you will eliminate the building of any html on the serverside >too How? In your own example you have to build the html. Regards, Gilberto
HTML parser was[Re: HTML5: data-* atrributes]
I've changed the subject as I don't think this is related to data attributes. It sounds as what you are after is an HTML parser that is smart enough to add the model data based on the server-side component ID. So is the use case to separate the designer from the developer? I think a developer is very fortunate if there is a dedicated designer for every page of the project. In my experience designers tend to be involved right in the beginning to design the site after which the developers take over. So forcing one to develop the markup for every page would mean a lot of duplication of effort, especially if the develop is alone in maintaining the application. Contrast that with: $table which renders all the markup. You also mention dynamic updating, but that sounded like Ajax? Btw, if I recall this is the way Wicket[1] works so there might already be an Apache project that provides what you are after. Kind regards Bob [1]: http://wicket.apache.org/ On 1/10/2010 02:45, florin.g wrote: > > Bob, > > Keep an open mind for a second. > > How about if we don't use velocity? > > Here's what I'd do, but I don't have the time (sometime I believe the > brains) to implement such a thing: > > Use the html element ID to identify the mapped java object on the server. > Process as needed - if text bound to server data (such as a first name of a > person), the client side would be a tag; if the element is a structural > element (table row, selection option) then the server side would do the > looping. > > Example 1: > > Dear , we announce a great party this weekend (). > > The example above will eliminate the use of velocity on the client side: > #firstName. > > Example 2: > > > > > Name tag color: > > > Now, the serverside will know that this a collection and will deal > accordingly. > > Why not? To me it is like a dream come true. Whenever I see php or jsp in an > html page, ah. Would this not eliminate velocity completely? Not only so, > but you will eliminate the building of any html on the serverside too. Page > designers will have full control over the page. The use of page fragments > will facilitate reusable components. > > Do I make any sense? > >
Re: HTML5: data-* atrributes
The SPAN tags were deleted above. What I try to say, that a piece of text that needs to be dynamically updated would be wrapped in a SPAN tag with a unique ID. -- View this message in context: http://click.1134972.n2.nabble.com/HTML5-data-atrributes-tp5583298p5588482.html Sent from the click-development mailing list archive at Nabble.com.
Re: HTML5: data-* atrributes
Bob, Keep an open mind for a second. How about if we don't use velocity? Here's what I'd do, but I don't have the time (sometime I believe the brains) to implement such a thing: Use the html element ID to identify the mapped java object on the server. Process as needed - if text bound to server data (such as a first name of a person), the client side would be a tag; if the element is a structural element (table row, selection option) then the server side would do the looping. Example 1: Dear , we announce a great party this weekend (). The example above will eliminate the use of velocity on the client side: #firstName. Example 2: Name tag color: Now, the serverside will know that this a collection and will deal accordingly. Why not? To me it is like a dream come true. Whenever I see php or jsp in an html page, ah. Would this not eliminate velocity completely? Not only so, but you will eliminate the building of any html on the serverside too. Page designers will have full control over the page. The use of page fragments will facilitate reusable components. Do I make any sense? -- View this message in context: http://click.1134972.n2.nabble.com/HTML5-data-atrributes-tp5583298p5588462.html Sent from the click-development mailing list archive at Nabble.com.
Re: HTML5: data-* atrributes
On 30/09/2010 12:20, florin.g wrote: > > So is it time to move away from using any scripting inside an html page? Not > even velocity? No not at all. These attributes are defined by the new HTML5 specification, so it could come in handy however you create the markup: The above markup will be valid HTML5, even though no attribute called "data-tooltip" exists for the div element. HTML5 is still evolving so this feature might not be in the final spec. I just though it is a useful feature. Kind regards Bob
Re: HTML5: data-* atrributes
So is it time to move away from using any scripting inside an html page? Not even velocity? -- View this message in context: http://click.1134972.n2.nabble.com/HTML5-data-atrributes-tp5583298p5586382.html Sent from the click-development mailing list archive at Nabble.com.
