subject:"Re\: Can Component Template be Informed by Page Class"

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
it as above, perhaps, "not the Tapestry way".  But of course it is not - LOL
- it is my way.   I want to improve it.   Just FYI, I considered all
comments except the ones that I could not get to work...(i.e. not ignoring
anything...)

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5684938.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-03 Thread Howard Lewis Ship

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.

But the model for Tapestry is that the container (the page, or
containing component) pushes data INTO the component, by establishing
bindings: properties of the container that can be read by the
component through its @Parameter-annotated fields.

It is possible for a component to have knowledge of its container:
the @InjectContainer annotation can be used for that purpose.

However, solutions based on the component having too much knowledge of
their container have been proven, in the wild to be brittle, hard to
understand, hard to maintain. I've seen this is client code I've had
to clean up (and the code is *always* shorter and clearer, as well).
The "right" way, which is to reason about the minimum set of
information a component needs to operate, has proven itself time and
again to be the best approach.

I often post a link to this document:
http://catb.org/esr/faqs/smart-questions.html

It goes into great length about how to phrase your question the
correct way to best ensure an answer. Part of the core is stripping
away as much as you can, to reduce it to a question of stimulus,
expected response, and actual response. "I pushed the button,
expecting the car to start, but instead the radio came on." is vastly
preferable to "I think the inputs on the dashboard need to be
reorganized."  Showing that you can think clearly, and ask questions
intelligibly, is very necessary to quickly prove yourself to others,
the people who could more easily ignore you than help you.

On Thu, May 3, 2012 at 1:34 PM, netdawg  wrote:
> 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,
> going off in tangents.   You now have something concrete.  Lets improve it
> together.  I have (and will ) incorporate many of those comments - just not
> all of them - unless I have code that actually works.  Just declaring try
> this and that is not sufficient.  Finally, as for time spent, we are all in
> the same canoe.  This is the only way this tool gets sharpened.
>
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5684235.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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,
going off in tangents.   You now have something concrete.  Lets improve it
together.  I have (and will ) incorporate many of those comments - just not
all of them - unless I have code that actually works.  Just declaring try
this and that is not sufficient.  Finally, as for time spent, we are all in
the same canoe.  This is the only way this tool gets sharpened.  

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5684235.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-03 Thread Thiago H. de Paula Figueiredo


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 inside clique that is bullying everyone else - helping some and  
not others - you have perfect right to do that, but that there will more

footsteps out the door than inpossibly mine too.  Good bye.


You didn't get the joke, but it's just because you haven't hang around  
here for longer. Taha Hafez has a very nice blog about Tapestry named  
Tapestry Magic: http://tawus.wordpress.com/.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-03 Thread Robert Zeigler

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 component (page)?  "

This suggests that you're thinking of the page as the child component. But the 
page isn't the child component. The page is the parent component.

You've also referred to pages "inheriting" from components:

"pages, like Index, are not inheriting layout etc, from component Layout? 
What am I missing?  "

There's no inheritance involved. Tapestry pages and components are generally 
built by composition, not inheritance.

Consider:
class Person {
   private String firstName;
   private String lastName;
}

Person is /composed/ of two String objects. But Person does not /inherit/ 
anything from String. It's not a String, it's a Person with two String 
properties. Likewise, String is not in any way tied specifically to Person.  
Imagine if the String object in java had some code like:

  if (containingObject.firstName.equals("George")) {...}

It's a bit preposterous, don't you think? :)

Yet, this is precisely what you're proposing.  Your Page is like the Person. It 
is composed of components, in an analogous way to how Person is composed of two 
String properties. 

Making your Components depend on specific details of the page (like whether it 
has a specific property) is a recipe for brittle components with no potential 
for reuse. Which is a shame because the point of components is reuse. 

All of that said, it's normal to adjust the behavior of the component to the 
requirements of the container. The two normal ways to do this are component 
parameters and the Environment service. Both of these solutions have been 
mentioned multiple times (3? 4?), but it appears that you are unfamiliar with 
the concepts, eg:

"I am not sure what the "Environment" solution referred really is. "

A good place to start is the documentation. :)
See:

http://tapestry.apache.org/component-parameters.html

For starters on component parameters, and:

http://tapestry.apache.org/environmental-services.html

For information on using the "Environment" solution.

Finally, you can accomplish directly what you're trying to do as:

Index.java:

public class Index implements MyInterface {

  public Object getSomeProperty() {..}//defined by MyInterface

}

Index.tml:

Layout.java:

@Inject
private ComponentSource cs;

@Inject
private ComponentResources resources;

@Cached
public MyInterface getMyInterfaceInstance() {
  Object o = cs.getPage(resources.getPageName());
  if (o instanceof MyInterface) {
 return (MyInterface) o;
  } else {
 return /* something else here, some reasonable value. null? Default 
implementation of MyInterface?*/;
  }
}

Layout.tml:
  ${myInterfaceInstance.someProperty}

But that's an awful lot of work for something that could be accomplished as:

public Class Index {
  public Object getSomeProperty() {...}
}

Index.tml:

Layout.java:
  @Parameter
  private Object parameterName;

Layout.tml:
  ${parameterName}

You didn't have to create the interface. Layout can be used on any page. And 
any property can be used to satisfy the need for "parameterName". 

Cheers,

Robert

On May 3, 2012, at 5/31:49 PM , 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 inside clique that is bullying everyone else - helping some and not
> others - you have perfect right to do that, but that there will more
> footsteps out the door than inpossibly mine too.  Good bye. 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5684049.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> 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: Can Component Template be Informed by Page Class

2012-05-03 Thread Lance Java

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 frustration

Re: Can Component Template be Informed by Page Class

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 not
others - you have perfect right to do that, but that there will more
footsteps out the door than inpossibly mine too.  Good bye. 

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5684049.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-03 Thread Thiago H. de Paula Figueiredo

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
component, using ComponentResources.getPage() or getPageName() you can
figure out in which page the component is, even if this is a bad approach
in most situations. People already do many magical things (Taha, wink! ;))
with Tapestry the way it is. If you explained better what you want to do
we'll be able to tell how you implement the Tapestry way. I'm not sure
I'll take the time, though.

On Thu, 03 May 2012 14:21:49 -0300, netdawg wrote:

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. The possibilities are simply fantastic. If Tapestry, cannot (or
will
not) do it - there are other frameworks who will. Waving your resume,
or

credentials, is not going to help in the face of sheer power of logic, or
the market. If you do not want to call it Polymorphism - fine - call it
sometihng else. I was using that term loosely to convey some sense of
different behavior based on what page the component is templating. The
objective here is to enhace that behavior, not block the very
consideration

of it.

--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5683836.html

Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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.  The possibilities are simply fantastic.  If Tapestry, cannot (or will
not)  do it - there are other frameworks who will.  Waving your resume, or
credentials, is not going to help in the face of sheer power of logic, or
the market.  If you do not want to call it Polymorphism - fine - call it
sometihng else.  I was using that term loosely to convey some sense of
different behavior based on what page the component is templating.  The
objective here is to enhace that behavior, not block the very consideration
of it.  

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5683836.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-03 Thread Thiago H. de Paula Figueiredo


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 properties - they use only  
those available - and if not, they behave as if those properties do not  
exist.

That is Polymorphism, for me.  So a shape would draw only if there was
concrete draw provided, other it would ignore the draw request.


No, this is not the definition of polymorphism in software development.  
Quite far from it, actually. You can have polymorphism without interfaces  
in Java:


int i = 2;
long x = i;

i is not a long, yet its value still can be assigned to a long. That's a  
type of polymorphism called coercion.


Polymorphism is the ability of something to appear in different forms in  
different contexts. Example: passing a String to a method that receives an  
Object. In this case, String appears as if it was an Object to this  
method. This is called inclusion polymorphism.


In addition, the dynamic typed languages are all about polymorphism.


2.  This discussion is about expanding horizons of Tapestry...


I don't see it that way. You're asking for Tapestry to have a feature that  
goes against its principles. To make things worse, there are way to do  
what you want already implemented in the framework.


I didn't want to pull an argument by authority, but I know what I'm  
talking about (at least in this case). When doing my master's degree, I  
was a TA in Object-Oriented Programming. Later I was the coordinator and  
professor of a graduate course on Java. I have more than 4360 posts in the  
Tapestry mailing lists. For helping people, I've been voted as a Tapestry  
committer and then a member of the Project Management Committee.



not saying
this a "Very Bad Thing etc" or giving up because it is difficult.


I'm not saying this is difficult. I'm saying it's the wrong thing to do.  
It goes against the principles of Tapestry, good practices and good  
architecture.



3.  I see pageName is just another page property...nothing more, nothing
less (or should be, if not).   Therefore, all other page properties  
should be visible as well.  Of course, I have not looked at the code...


No, the page name is not just another page property. That method in  
ComponentResources returns the logical name of the page, which is part of  
the not a property of your page class. You insist in saying this.


That said, THANKS, I like the idea of  
ComponentResources.getPage()...*may*
indeed be the answer I was look for...but I am already on a roll, so  
perhaps will look into later and report back


You're welcome!

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-02 Thread Geoff Callender

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 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
>
> We would all agree that the menu should be a component, say, Layout.tml:
>
>
>  
>
> 
>
>   index?tabId=0 Home 
>   tab1?tabId=1 Table1 
>   tab2?tabId=2 Table2 
>
>  [..and so on.. ]
>
>
> 
>
> 
>
>
>
>
> I was struggling with where to put the tabId(X) that needs to be passed
> from
> page(X) to activate body id and class tab(X).   Dilemma: Should the ids be
> properties of each of the pages?  They would then pass it to the layout
> component somehow.  Either by setting the component parameter tabId from
> each page class or by have component read the tabId (impossible) - either
> way plenty of code.  Now I am just passing it as a request parameter - for
> each tab.  All my tabX classes are empty shells.  I just need to receive it
> in the component as request parameter.  The Laoyout.tml code is very
> readable as well.
>
> I am not sure what the "Environment" solution referred really is.  If you
> have an example (and time!), I will be happy to consider.  Even a whole new
> way to do tabs perhaps?  But not urgent...as I said...I have found a way
> (or
> a hack? Eye of the beholder ;-)).
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681966.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: Can Component Template be Informed by Page Class

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 

We would all agree that the menu should be a component, say, Layout.tml: 


 

 
 
   index?tabId=0 Home 
   tab1?tabId=1 Table1 
   tab2?tabId=2 Table2 

  [..and so on.. ]

 
 

 




I was struggling with where to put the tabId(X) that needs to be passed from
page(X) to activate body id and class tab(X).   Dilemma: Should the ids be
properties of each of the pages?  They would then pass it to the layout
component somehow.  Either by setting the component parameter tabId from
each page class or by have component read the tabId (impossible) - either
way plenty of code.  Now I am just passing it as a request parameter - for
each tab.  All my tabX classes are empty shells.  I just need to receive it
in the component as request parameter.  The Laoyout.tml code is very
readable as well.  

I am not sure what the "Environment" solution referred really is.  If you
have an example (and time!), I will be happy to consider.  Even a whole new
way to do tabs perhaps?  But not urgent...as I said...I have found a way (or
a hack? Eye of the beholder ;-)).  

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681966.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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 not, they behave as if those properties do not exist.
That is Polymorphism, for me. So a shape would draw only if there was
concrete draw provided, other it would ignore the draw request.

2. This discussion is about expanding horizons of Tapestry...not saying
this a "Very Bad Thing etc" or giving up because it is difficult. That is
why we can have JIRA (let it be in Version 7). Or citing some principles
that are yet to be articulated fully...for all I know, we are doing that
now. Basically, it is about more magic, not less functionality.

3. I see pageName is just another page property...nothing more, nothing
less (or should be, if not). Therefore, all other page properties should
be visible as well. Of course, I have not looked at the code...

That said, THANKS, I like the idea of ComponentResources.getPage()...*may*
indeed be the answer I was look for...but I am already on a roll, so perhaps
will look into later and report back

--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681962.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class


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 "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 of a circle it would be a radius, for rectangle - two sides etc.


This doesn't change the fact that they should be self-contained: in other  
words, all code to implement its logic inside itself, not scattered.


Either way, when using Tapestry, you should use the definition of  
'component' that Tapestry uses. And don't try to go against the principles  
used to build a framework when you're using it.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class


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 attribute if the INTENT was otherwise (that is, as you are
suggesting, the component to be oblivious to the page)?


I haven't understood what you're trying to do with it, so I didn't answer.

And if it does already have pageName, why not access to  
pageName.property?


Because they're very, very, very different stuff. Each component instance  
belongs to a page, so ComponentResources.getPageName() is actually an easy  
thing to implement. On the other hand, getting properties from the page  
itself is a whole different matter. In addition, tying a component to a  
given page is a very bad thing to do (you couldn't use the component in  
another page).


A component accessing a page property, believe me, is a Very Bad Thing.  
It's bad architecture. It's going against the philosophy on which Tapestry  
was build. I really don't know what good would come from doing what a  
framework doesn't want you to do.



To me, it seems counter-intuitive to place a property of a page into a
component and to then have it trickle  back down to the page...when the
component could simply access the property directly (just like it does  
the pageName).


That's the point: getting the page name is one thing, getting page  
properties would need a whole different code for it. And it would still be  
a very bad idea.


On the other hand, you can get the page instance by invoking  
ComponentResources.getPage() and casting the returned object to the page  
class.


the message (best practice according to you guys) is to use the getters  
and setters of the component class from the page class...


Nope. It's passing parameters to the components or using the Environment.

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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 of a
circle it would be a radius, for rectangle - two sides etc.  

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681782.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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
pagename attribute if the INTENT was otherwise (that is, as you are
suggesting, the component to be oblivious to the page)?

And if it does already have pageName, why not access to pageName.property?

To me, it seems counter-intuitive to place a property of a page into a
component and to then have it trickle back down to the page...when the
component could simply access the property directly (just like it does the
pageName).

Also, I did review Lance's example...the images are not being pulled up, so
it is a bit of a hard read. Also, it does not seem to be getting any
parameters from a page. Unless...

the message (best practice according to you guys) is to use the getters and
setters of the component class from the page class...presumably with one of
pre-rendering event handlers...which is essentially the same operation (for
simple strings like ids) as request parameter...?

--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681722.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class


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.pageName  is a step in the right direction.   I  
am

just asking to extend it further



 Question does not make sense...


pages, like Index, are not inheriting layout etc, from component Layout?


No. Page uses Layout component, but it doesn't mean that page inherits  
from Layout. Layout is a component as any other.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class


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 Tapestry web app.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

2012-05-02 Thread Lance Java

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 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 will have to be called by invoked index?pageProperty=
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681501.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: Can Component Template be Informed by Page Class

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-tp5681397p5681540.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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,* if the page class is ever renamed or moved to a different
package, the pageName property will automatically adjust to the new name*.
...This is what I am talking about.  



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681531.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

>>>  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 further


>>>  Question does not make sense...

pages, like Index, are not inheriting layout etc, from component Layout? 
What am I missing?  

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681512.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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 will have to be called by invoked index?pageProperty=

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Can-Component-Template-be-Informed-by-Page-Class-tp5681397p5681501.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class

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 Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class


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.pageProperty}
What do you guys think - JIRA worthy???


I don't think so. It violates the self-contained principle for components  
very badly. Use parameters or the Environment instead.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class


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  
parameters or the Environment.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Can Component Template be Informed by Page Class