Re: some old criticisms of T5
In my experience Tapestry generates better HTML than many (most?) of other frameworks. Lets take for example the whitespace issue. In most cases whitespace in templates are artefacts of indentation used to improve readability of templates during development. As the result when blindly preserved, whitespace in generated HTML is just ton of unnecessary garbage. E.g. it is not uncommon to see several empty lines at the start of generated HTML from JSP-powered frameworks. Tapestry approach is much more efficient. Regarding, using a complain about problems with using Tapestry-generated page as responses to AJAX calls, I believe that Tapestry offers better solution with custom document builder dedicated for AJAX and returning a custom structure. While just returning HTML snippets for AJAX can work for simple applications, it becomes maintainability nightmare for more complex once: how to ensure that necessary CSS-es, JavaScripts are included but not duplicated (and when pages are generated from multiple reusable components that do not know about each other), how to insert the response into multiple parts of the page, how to avoid DOM id conflicts, how to handle errors in a friendly way. All of this is provided by Tapestry from the start. Another complain was problems with XHTML, thankfully it almost died. Best regards, Cezary On Mon, Sep 19, 2016 at 6:36 PM, Qbyte Consulting wrote: > No, HLS replies were spot on. The only irritation I have found with T5 is > some of the default styling that gets added to handle form errors and these > can be overriden with your own css - can be mucky, but works. > > On Mon, Sep 19, 2016 at 5:23 PM, Bob Harner wrote: > > > That's a very old article (2009 -- I don't think many users care about > > IE6 redering quirks anymore), but Howard's comments there seem to do a > > pretty good job of explaining where the author is either mistaken or > > misunderstands the constraints and trade-offs involved. A lot of the > > other commenters do likewise. I don't know if there is much more to > > add, is there? > > > > On Mon, Sep 19, 2016 at 11:13 AM, Qbyte Consulting > > wrote: > > > https://friendlybit.com/html/tapestry-5-and-how-not-to-treat-html/ > > > > > > I'm wondering how users would respond to the above. I haven't found > these > > > issues a big problem myself, but some of these behaviours are > > problematic, > > > for example someone mentioned the white-space issue recently. > > > > > > John > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
Re: org.apache.tapestry5.services.javascript.Initialization.with(Object... arguments)
I was thinking about that but never tried as it doesn't seem intuitive
at all :) But thanks for the hint, I will refactor.
Adam
On Thu, Sep 22, 2016 at 6:06 PM, Cezary Biernacki wrote:
> You can do:
>
> jsSupport.require("foo").invoke("myFunc").with("bar");
>
> Best regards,
> Cezary
>
>
> On Thu, Sep 22, 2016 at 5:54 PM, Adam X wrote:
>
>> Is there a reason this is not a fluid setter? Right now I have to do:
>>
>> Initialization foo = jsSupport.require("foo");
>> foo.with("bar");
>> foo.invoke("myFunc");
>>
>> I'd rather just do:
>>
>> jsSupport.require("foo").with("bar").invoke("myFunc")
>>
>>
>> but with(Object...) returns void :(
>>
>> Adam
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: org.apache.tapestry5.services.javascript.Initialization.with(Object... arguments)
You can do:
jsSupport.require("foo").invoke("myFunc").with("bar");
Best regards,
Cezary
On Thu, Sep 22, 2016 at 5:54 PM, Adam X wrote:
> Is there a reason this is not a fluid setter? Right now I have to do:
>
> Initialization foo = jsSupport.require("foo");
> foo.with("bar");
> foo.invoke("myFunc");
>
> I'd rather just do:
>
> jsSupport.require("foo").with("bar").invoke("myFunc")
>
>
> but with(Object...) returns void :(
>
> Adam
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: org.apache.tapestry5.services.javascript.Initialization.with(Object... arguments)
Wouldn't jsSupport.require("foo").invoke("myFunc").with("bar"); Work?
IMHO if the library is your own (a bit from a mixin that adds a spinner on ajax
buttons and then removes it on a response),
ajaxResponseRenderer.addCallback((JavaScriptCallback) javascriptSupport -> {
javascriptSupport.require("spin.wait").with(new
JSONObject().put("spinWaitId", id));
});
define(["jquery"], function ($) {
return function (response) {
$('#' + response.spinWaitId).find('button').removeClass('loading');
}
});
-Original Message-
From: Adam X
To: Tapestry users
Sent: Thu, Sep 22, 2016 11:54 am
Subject: org.apache.tapestry5.services.javascript.Initialization.with(Object...
arguments)
Is there a reason this is not a fluid setter? Right now I have to do:
Initialization foo = jsSupport.require("foo");
foo.with("bar");
foo.invoke("myFunc");
I'd rather just do:
jsSupport.require("foo").with("bar").invoke("myFunc")
but with(Object...) returns void :(
Adam
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
org.apache.tapestry5.services.javascript.Initialization.with(Object... arguments)
Is there a reason this is not a fluid setter? Right now I have to do:
Initialization foo = jsSupport.require("foo");
foo.with("bar");
foo.invoke("myFunc");
I'd rather just do:
jsSupport.require("foo").with("bar").invoke("myFunc")
but with(Object...) returns void :(
Adam
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: beaneditform with option lists of objects
You will need to build a select model for your list http://tapestry.apache.org/using-select-with-a-list.html I would create an Interface and have the child implement it so you can create a generic one Then create an edit block out of that code. This will allow the BeanEditor to edit this kind of list with your edit block Lastly since the type is likely list or set you will need to annotate the field with @Datatype so the bead editor can figure out what block to use to edit the field. You might be able to write a data type analyzer to figure this out without @Datatype but Java's type erasure makes this a bit difficult. It sounds like a lot of work but once you've done one it gets easier. Also if you create a generic select model you'll only need one. On Wednesday, September 21, 2016, Paul Stanton wrote: > Hi all, > > I have tables: > Parent > -- > parent_id > child_id > > Child > --- > child_id > > and ORM entity: > > Parent > --- > Long Id > Child child (oneToOne in this case, joinColumn child_id) > > Child is another ORM entity. Child could be one of many options from the > database. > > I would like a form for editing Parent which using a allows the > selection of one Child from all of the Child options. > > What is the easiest way to integrate this model with BeanEditForm or > failing that, BeanEditor? > > Thanks, Paul. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
