You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Andrew Arrow <an...@verizon.net> on 2005/01/07 16:07:58 UTC
to be abstract or not to be...
What's the advantage to making your page/component classes abstract and
defining properties vs. just making it a normal class with real getters
and setters?
I find myself creating real member variables in the class and using the
Eclipse feature to auto-generate getters and setters. i.e. all I have
to type is:
Date date;
String event;
and the rest of the work is done for me. The other way I'm on the hook
for typing:
public abstract void setDate(Date date);
public abstract void setEvent(String event);
public abstract Date getDate();
public abstract String getEvent();
<property-specification name="date" type="java.lang.Date" persistent="yes"/>
<property-specification name="event" type="java.lang.String"
persistent="yes"/>
Thanks,
-Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page render time in source code (and generator meta tag)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 7, 2005, at 1:35 PM, kranga wrote:
> I agree with everything you have said. However, when dealing with IT
> department regulations, arguments will not help. Do you know how to
> take the
> generator tag out?
Don't use the @Shell component - thats the only way to do it, or modify
Tapestry's source code.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page render time in source code (and generator meta tag)
Posted by kranga <kr...@k2d2.org>.
I agree with everything you have said. However, when dealing with IT
department regulations, arguments will not help. Do you know how to take the
generator tag out?
H.L. Ship, please shed some light...
----- Original Message -----
From: "Jim Zajkowski" <ji...@jimz.net>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, January 07, 2005 12:57 PM
Subject: Re: Page render time in source code (and generator meta tag)
> On Jan 7, 2005, at 12:43 PM, kranga wrote:
>
> > I don't want the world to know that the application uses Tapestry for
> > obvious security reasons...
>
> Personally, I can't think of an obvious security reason.
>
> From my experience, attackers usually fall into three categories:
> motivated but not skilled; the motivated, professional sophisticated
> attacker; and insiders.
>
> Generally speaking, the first group will try every wrench they know,
> and it doesn't matter if you tell them you're using Tapestry or not. I
> think anyone who has dumb IIS exploits appearing in their apache logs
> knows about this.
>
> Or the attacker is sophisticated and will be able to figure it out
> either way. They may be financially motivated or funded. You really
> won't be able to hide what your back-end is using from them, and they
> may not need to know.
>
> TCP fingerprinting can reveal a host's operating system. HTTP headers,
> URLs, form names, and other protocol bits all dead give-aways.
>
> --Jim
>
> --
> Jim Zajkowski OpenPGP 0x21135C3 http://www.jimz.net/pgp.asc
> System Administrator 8A9E 1DDF 944D 83C3 AEAB 8F74 8697 A823 2113 5C53
> UM Life Sciences Institute
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page render time in source code (and generator meta tag)
Posted by Jim Zajkowski <ji...@jimz.net>.
On Jan 7, 2005, at 12:43 PM, kranga wrote:
> I don't want the world to know that the application uses Tapestry for
> obvious security reasons...
Personally, I can't think of an obvious security reason.
From my experience, attackers usually fall into three categories:
motivated but not skilled; the motivated, professional sophisticated
attacker; and insiders.
Generally speaking, the first group will try every wrench they know,
and it doesn't matter if you tell them you're using Tapestry or not. I
think anyone who has dumb IIS exploits appearing in their apache logs
knows about this.
Or the attacker is sophisticated and will be able to figure it out
either way. They may be financially motivated or funded. You really
won't be able to hide what your back-end is using from them, and they
may not need to know.
TCP fingerprinting can reveal a host's operating system. HTTP headers,
URLs, form names, and other protocol bits all dead give-aways.
--Jim
--
Jim Zajkowski OpenPGP 0x21135C3 http://www.jimz.net/pgp.asc
System Administrator 8A9E 1DDF 944D 83C3 AEAB 8F74 8697 A823 2113 5C53
UM Life Sciences Institute
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page render time in source code (and generator meta tag)
Posted by Paul Ferraro <pm...@columbia.edu>.
kranga wrote:
>1) What exactly does the page render time measure?
>
The duration of the Shell component's render cycle.
> Time from request being
>received to time when response started to stream to client?
>
The measured time has only relative meaning since it will most likely
include a mix of both buffering and streaming.
Determining when streaming actually happens is somewhat complicated
since there is buffering happening all over the place:
* the AbstractMarkupWriter internally uses a BufferedWriter
* the ResponseOutputStream (wraps ServletOutputStream) has a default
max buffer size of 2000 and defers the opening of the ServletOutputStream.
* the Body component buffers its entire output
* your servlet container's ServletOutputStream implementation may also
choose to implement its own buffering.
> Does tapestry
>buffer the full response before sending it out?
>
No - although the Body component buffers it's full output.
> Does the time also include
>sending the stream till the last bit (because on a slow connection, that
>will report an incorrect value).
>
>
>
No - the Shell component does not flush its HTMLMarkupWriter.
>2) How do I stop the generator meta tag from being displayed? I don't want
>the world to know that the application uses Tapestry for obvious security
>reasons...
>
>
>
The generator meta tag as well as header/footer comments are generated
by the Shell component.
The only way to omit these is to not use the Shell component. Writing
your own is fairly trivial.
Paul
>Thanks
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Page render time in source code (and generator meta tag)
Posted by kranga <kr...@k2d2.org>.
1) What exactly does the page render time measure? Time from request being
received to time when response started to stream to client? Does tapestry
buffer the full response before sending it out? Does the time also include
sending the stream till the last bit (because on a slow connection, that
will report an incorrect value).
2) How do I stop the generator meta tag from being displayed? I don't want
the world to know that the application uses Tapestry for obvious security
reasons...
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: to be abstract or not to be...
Posted by Marcus Brito <mb...@gmail.com>.
You did. Eclipse has (not quite) everything IDEA has for free because
they just copy it from IDEA. Fortunately (for Eclipse, and for the
software development community in general), JetBrains head figures
commented once on how they dislike software patents, and they won't
patent a single IDEA feature. They want to stay competitive for their
own technical merits, not for legal issues or for just 'being the
first'.
That being said... you might want to review the two IDE's features.
There's lot of functionality available in IDEA not available in
Eclipse (at least without commercial plugins), and even when they both
have the same features there's a remarking different on how they are
implemented, specially on the interface and usability arena.
On Fri, 7 Jan 2005 12:01:23 -0500, kranga <kr...@k2d2.org> wrote:
> If Idea has it, eclipse has it ... for free :)
>
> Oh no! I just started a war!!!
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: to be abstract or not to be...
Posted by kranga <kr...@k2d2.org>.
If Idea has it, eclipse has it ... for free :)
Oh no! I just started a war!!!
----- Original Message -----
From: "Vince Marco" <vm...@mac.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, January 07, 2005 11:49 AM
Subject: Re: to be abstract or not to be...
> I understand why a property needs to be declared in order to be
> initialized. Can't I implement the setters and getters and still
> declare the property in the page/component config, though? These
> should still get initialized between users of a page instance.
>
> My implementing setters/getters shouldn't prevent proper initialization
> of properties between pages. This seems like a case of the framework
> needlessly dictating a narrow path for developers to follow, if this is
> the case. I would think that the framework should be able to handle
> both types of setters/getters for declared properties.
>
> In my Tapestry apps, I just followed the example and didn't get too
> caught up in abstract vs. implemented setters/getters. I do think
> there are places where Tapestry does seem a bit awkward, given the
> coding tools in Eclipse and Idea. However, these all seem fairly minor
> compared to the advantages I realize. I mainly use Idea, which also
> has a "live text" feature for setting up your own insert macros, which
> works very well in declaring abstract setters/getters. I don't know if
> this feature is in Eclipse.
>
> Vince
>
> On Jan 7, 2005, at 8:43 AM, Danny Mandel wrote:
>
> > The advantage to being abstract and not using instance variables is
> > that you don't have to worry about incorrect values showing up across
> > different sessions. Tapestry pages are pooled, so there is almost
> > certainly going to be some sharing of page objects. If you use
> > standard getters/setters and don't reinitialize the values to a clean
> > state, then instance data for one user could show up in another user's
> > session.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: to be abstract or not to be...
Posted by Vince Marco <vm...@mac.com>.
I understand why a property needs to be declared in order to be
initialized. Can't I implement the setters and getters and still
declare the property in the page/component config, though? These
should still get initialized between users of a page instance.
My implementing setters/getters shouldn't prevent proper initialization
of properties between pages. This seems like a case of the framework
needlessly dictating a narrow path for developers to follow, if this is
the case. I would think that the framework should be able to handle
both types of setters/getters for declared properties.
In my Tapestry apps, I just followed the example and didn't get too
caught up in abstract vs. implemented setters/getters. I do think
there are places where Tapestry does seem a bit awkward, given the
coding tools in Eclipse and Idea. However, these all seem fairly minor
compared to the advantages I realize. I mainly use Idea, which also
has a "live text" feature for setting up your own insert macros, which
works very well in declaring abstract setters/getters. I don't know if
this feature is in Eclipse.
Vince
On Jan 7, 2005, at 8:43 AM, Danny Mandel wrote:
> The advantage to being abstract and not using instance variables is
> that you don't have to worry about incorrect values showing up across
> different sessions. Tapestry pages are pooled, so there is almost
> certainly going to be some sharing of page objects. If you use
> standard getters/setters and don't reinitialize the values to a clean
> state, then instance data for one user could show up in another user's
> session.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: to be abstract or not to be...
Posted by Danny Mandel <dm...@tolweb.org>.
The advantage to being abstract and not using instance variables is that
you don't have to worry about incorrect values showing up across
different sessions. Tapestry pages are pooled, so there is almost
certainly going to be some sharing of page objects. If you use standard
getters/setters and don't reinitialize the values to a clean state, then
instance data for one user could show up in another user's session.
There's a more thorough explanation of the process here:
http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/state.page-properties.html
Hope that helps,
Danny
kranga wrote:
>I can see the advantage if you need the properties to be persistent, but I'd
>be very interested in knowing if there is any reason to do this if you
>properties are not going to be persistent.
>
>----- Original Message -----
>From: "Andrew Arrow" <an...@verizon.net>
>To: "Tapestry users" <ta...@jakarta.apache.org>
>Sent: Friday, January 07, 2005 10:07 AM
>Subject: to be abstract or not to be...
>
>
>
>
>>What's the advantage to making your page/component classes abstract and
>>defining properties vs. just making it a normal class with real getters
>>and setters?
>>
>>I find myself creating real member variables in the class and using the
>>Eclipse feature to auto-generate getters and setters. i.e. all I have
>>to type is:
>>
>>Date date;
>>String event;
>>
>>and the rest of the work is done for me. The other way I'm on the hook
>>for typing:
>>
>>public abstract void setDate(Date date);
>>public abstract void setEvent(String event);
>>public abstract Date getDate();
>>public abstract String getEvent();
>>
>><property-specification name="date" type="java.lang.Date"
>>
>>
>persistent="yes"/>
>
>
>><property-specification name="event" type="java.lang.String"
>>persistent="yes"/>
>>
>>Thanks,
>>-Andrew
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: to be abstract or not to be...
Posted by kranga <kr...@k2d2.org>.
I can see the advantage if you need the properties to be persistent, but I'd
be very interested in knowing if there is any reason to do this if you
properties are not going to be persistent.
----- Original Message -----
From: "Andrew Arrow" <an...@verizon.net>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, January 07, 2005 10:07 AM
Subject: to be abstract or not to be...
> What's the advantage to making your page/component classes abstract and
> defining properties vs. just making it a normal class with real getters
> and setters?
>
> I find myself creating real member variables in the class and using the
> Eclipse feature to auto-generate getters and setters. i.e. all I have
> to type is:
>
> Date date;
> String event;
>
> and the rest of the work is done for me. The other way I'm on the hook
> for typing:
>
> public abstract void setDate(Date date);
> public abstract void setEvent(String event);
> public abstract Date getDate();
> public abstract String getEvent();
>
> <property-specification name="date" type="java.lang.Date"
persistent="yes"/>
> <property-specification name="event" type="java.lang.String"
> persistent="yes"/>
>
> Thanks,
> -Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org