1. Removing @Persist breaks the input form - as designed - not using
beaneditor, beaneditform.
2. Changing the person field breaks the grid - again, as designed -
workaround being context=0.
3. I have removed the onActivate, OnPassivate - easy.
As I see it the app is hanging together, no
I've just gone through the thread here
http://tapestry.1045711.n5.nabble.com/Pagelink-above-grid-picks-up-context-from-last-pagelink-in-grid-td5660049.html
And I've taken out a few comments:
---
Can I see the serverside code for your edit page? I get the fe
Thanks, for chiming in, Howard.
Somewhat gratified by your perspective as this being more like
"shades-of-grey" rather than "black-and-white".
May be I should have asked differently...bit upset with the group, though,
for asking me to post code and then essentially ignoring it, even maligning
There's doing things a little different, and then there's driving on
the wrong side of the road ... on the highway.
There's specific reasons for many of the constraints in Tapestry,
often related to efficiency, security, encouraging users to create
maintainable code, or simply general correctness.
All:Again, I appreciate the inputs, efforts and suggestions, even good
advice. And, if someone does something differently, it is not "hacky".
The blog post, BTW, was for you specifically for your constructive comments.
I was inspired to do that since we were just waving hands on this forum
On Thu, 03 May 2012 15:49:19 -0300, netdawg wrote:
Good grief. O well, that is probably more oxygen for others. Thanks
for you inputs nevertheless - the ones with substance, anyway. As for
"wink, wink, we are already doing magic" - it borders on delusional -
suggesting some
sort of ins
You /do/ realize that Thiago has already spent considerable time trying to help
you?
In any event, your conceptual understanding of Tapestry seems a bit off. Not
trying to be mean, just stating fact. For instance:
"Basically, is there is a way for a component to "inherit" properties of
child co
Netdawg, this is not the first time you've come on the list, been given
good advice, ignored it and done your own hacky thing
This blog post of yours is ignoring every piece of advice you were given on
the list http://crudsqbe.wordpress.com/2012/04/29/tapestry
I can understand thiago's frustratio
Good grief. O well, that is probably more oxygen for others. Thanks for you
inputs nevertheless - the ones with substance, anyway. As for "wink, wink,
we are already doing magic" - it borders on delusional - suggesting some
sort of inside clique that is bullying everyone else - helping some and
I officially give up. You're using wrong definitions of concepts, and the
consequence is that just you will understand what you're talking about.
And you can't read my mind to know what I'm thinking. You have proven
nothing beyond the fact that you don't know what polymorphism is. In a
comp
Thiago, I perfectly understand where you are coming from. But it is hardly
defensible. And, I suspect you know it. I have just proven to you
polymorphic behavior of components using just pageName. Imagine what else
can done, in menus alone, with more visibility - multi-level drill-downs
etc.
On Wed, 02 May 2012 21:28:05 -0300, netdawg wrote:
OK. Lets leave it at that, I guess. Agree to disagree ;-).
1. Polymorphism is not about implementation at all. It is about
interfaces, which is what Components can aspire to be, sort of. In that
case, components, do not get tied to page
This example is very simple but easily enhanced:
http://jumpstart.doublenegative.com.au/jumpstart/together/withlayout/helloworld
But I'm not clear on whether it achieves the functionality/behaviour that
you require.
Geoff
On 3 May 2012 10:34, netdawg wrote:
> All this theoretical discussion a
All this theoretical discussion aside, what I am trying to do is this --
create a tabbed menu - should have mentioned that earlier, sorry...I thought
I was simplifying the discussion, but it got carried off on a different path
Specifically, http://unraveled.com/publications/css_tabs/ CSS Tabs 2.0
OK. Lets leave it at that, I guess. Agree to disagree ;-).
1. Polymorphism is not about implementation at all. It is about
interfaces, which is what Components can aspire to be, sort of. In that
case, components, do not get tied to page properties - they use only those
available - and if n
On Wed, 02 May 2012 19:19:43 -0300, netdawg wrote:
For the component to pick up page property would make it "Polymorphic".
Regarding your mention of polymorphism and quoting Princess Bride, "I do
not think it means what you think it means.".
Components, for instance, can then just be a "s
On Wed, 02 May 2012 18:46:59 -0300, netdawg wrote:
BTW, I just posted a citation which describes the
componentResources...which
is already able to pull up the pageName...this is very useful in
authoring solid code at the page level. Why would componentResources
have the
pagename attribut
For the component to pick up page property would make it "Polymorphic".
Components, for instance, can then just be a "shape" with an abstract draw()
method. The page will tell it what the shape is and what exactly the draw
method will do or for that matter what those parameters are - in case o
Right back at you guys on citations ;-). What principles is this breaking?
BTW, I just posted a citation which describes the componentResources...which
is already able to pull up the pageName...this is very useful in authoring
solid code at the page level. Why would componentResources have the
On Wed, 02 May 2012 17:12:38 -0300, netdawg wrote:
It violates the self-contained principle for components very badly.
Sorry - Disagree. Components are NOT meant to be "self-contained". They
are supposed to govern sub-components.
[Citation needed]
In fact,
prop:componentResources.pageNa
On Wed, 02 May 2012 16:59:41 -0300, netdawg wrote:
By parameters do you mean - pass dynamic run-time (request) parameters
to a page that is picked up instead by the containing component?
No. Tapestry component parameters. There's no reason for you to use
request attribute in a pure Tapestr
I totally agree with Thiago... you are trying to break tapestry's (very
sensible) principles.
Take a look at the link I sent you originally... pass a component parameter
(not a request parameter) from the page to the layout or use the
Environment.
On 2 May 2012 21:06, netdawg wrote:
> OK...I th
In other words, why is this "bad"? What specific dangers, problems do you
see? I see only more convenience. If, by bad, you mean in poor taste -
just don't use it.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp568139
From:
http://tapestry.apache.org/link-components-faq.html
Every component has an extra property, componentResources, added to it
it's the instance of ComponentResources that represents the link between
your code and all of Tapestry's structure around your class. . As an
added benefit,*
>>> It violates the self-contained principle for components very badly.
Sorry - Disagree. Components are NOT meant to be "self-contained". They
are supposed to govern sub-components. In fact,
prop:componentResources.pageName is a step in the right direction. I am
just asking to extend it f
OK...I think I got it...this works...swapping the property to the component
instead and have it intercept the page request
Layout.java :
public class Layout
{
@ActivationRequestParameter
@Property
private String pageProperty= "default";
}
Index.java is now empty
But Index page wi
By parameters do you mean - pass dynamic run-time (request) parameters to a
page that is picked up instead by the containing component?
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681479.html
Sent from the Ta
On Wed, 02 May 2012 16:33:05 -0300, netdawg wrote:
This may be a somewhat of a useful stand-in for the pageProperty...
${prop:componentResources.pageName}
It gets you the page name...and can be put in the component.
However, something like this would be useful
${prop:componentResources.pageName
On Wed, 02 May 2012 16:16:14 -0300, netdawg wrote:
Basically, is there is a way for a component to "inherit" properties of
child component (page)?
Pages cannot be child of components, so your question doesn't make sense.
For communication between pages, components and mixins, you can use
p
This may be a somewhat of a useful stand-in for the pageProperty...
${prop:componentResources.pageName}
It gets you the page name...and can be put in the component.
However, something like this would be useful
${prop:componentResources.pageName.pageProperty}
What do you guys think - JIRA
It might be possible but it's not recommended ;)
Can you just pass a property from the page to the layout?
http://wiki.apache.org/tapestry/Tapestry5Layoutcomponent
31 matches
Mail list logo
