Re: Jetty lock on JS-files in classpath breaks eclipse autobuild

[Luther Baker]

I had this same problem - but it was solved with the
useFileMappedBuffer=false solution. One difference was that I didn't change
/etc/webdefault.xml - I actually copied webdefault.xml into my project and
updated my pom file:


org.mortbay.jetty
maven-jetty-plugin

/bingo
3

src/main/config/jetty/webdefault.xml
 

  9090
  6

  
  


If it isn't clear, I use jetty:run ala maven from within my Eclipse
environment. Obviously, every project ends up with a copy of webdefault.xml,
but otherwise it turned out to be a straightfoward fix.

-Luther





On Wed, Oct 28, 2009 at 11:02 AM, Felix Gonschorek wrote:

> Hi Inge,
>
> one of our developers had the same issues (eclipse, jetty, maven) on
> windows XP - we tried several configurations (including the disabled jetty
> lock) without success. the problem disappeared after a fresh install of
> windows xp; we could not get rid of the problem with in any other way (tried
> several jetty configurations, re-installed eclipse and jre, disabled
> locking, ...)
>
> the lock occured on css files.
>
> the problem has not occured on linux or mac development machines.
>
> just to let you know, that you are not alone with this problem :)
>
>
> felix
>
> Inge Solvoll schrieb:
>
>  Hi!
>>
>> I'm having problems with my development environment.
>>
>> First of all: I have set the useFileMappedBuffer=false in
>> /etc/webdefault.xml
>>
>> My problem is that Tapestry 5 Javascript files located in WEB-INF/classes
>> and subfolders are locked by Jetty. This prevents eclipse from deleting
>> WEB-INF/classes to do a rebuild after I make a change in a java file. The
>> end result is that most class files are deleted and not rebuilt, so I have
>> to stop jetty, do a manual rebuild, and then start Jetty again. This if,
>> of
>> course, a disaster for me...
>>
>> Does anyone here have a clue on how to prevent Jetty from locking the
>> resource files in WEB-INF/classes?
>>
>>
>>
>

Re: Switch from Prototype to jQuery?

[Luther Baker]

>
> It would be very nice to have Tapestry components be more Javascript
> framework agnostic, but pushing Howard (and the other committers too, they
> exist!, hehehe) to do this and not working on other issues (after all, this
> is all about fixing something that already works, just doesn't work as good
> as we wished) wouldn't be a wise thing to do.


Great thread and I'm really not trying to take away from the momentum - but
per this last idea ... I'd keep in mind that the one of Tapestry's goal is
to increase marketshare.

I'd suggest that, while Javascript agnosticism may not be the top priority
amongst *current* users, I think that in general, it ranks up there (along
with documentation) as being pretty important going forward. It is really
quite an integral part of anything Web 2.0ish.

< $0.02.

-Luther

Re: blog, wiki, chat, alert, poll components

[Luther Baker]

If you want to allow that much control - you are likely relegated to JSPs.

-Luther



On Tue, Jun 9, 2009 at 6:42 AM, Christian Senk <
senk.christ...@googlemail.com> wrote:

> But with this technique you replace only the stylesheets,
> it is not possible in T5 to replace the generated HTML from skin to skin
> like in Wordpress because the TML and the Java-class are strongly wired
> together, or?
> This would be really great ^.^
>
> Greetings, Christian
>
> Onno Scheffers schrieb:
>
>  Skinning means you drop in a skin to some folder and everything changes
>>> automatically. With the layout component you have to manually adjust it.
>>> Core support means, that there is a core mechanism to find skins
>>> automatically and be able to change the looks at runtime for example with
>>> a
>>> listbox "Skinchanger".
>>>
>>>
>>
>>
>>
>> Skinning isn't that hard to do actually.
>> We have it in our application where each organisation or user can set a
>> default skin. Each skin has its own sub-folder and you simply change the
>> path to the css-files based on the user that is logged in. That css-file
>> can
>> override the default Tapestry styles if needed.
>>
>> In our solution we have to distribute all available skins along with the
>> application, but it would be possible to store/retrieve css-files, images
>> and js-files from a database as well..
>>
>> I'm currently cleaning up the stylesheets throughout our application and
>> replacing whatever I can with styles from jQuery UI CSS Framework (
>> http://jqueryui.com/docs/Theming/API). This means it gets much easier for
>> non-techies to create custom skins with the ThemeRoller (
>> http://jqueryui.com/themeroller/).
>>
>>
>> We do have a need for forum-functionality as well, but it is only on the
>> agenda for somewhere next year. So if nothing is available by then we may
>> have to write our own module then.
>>
>> regards,
>>
>> Onno
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: Web framework evaluation - What is beautiful in Tapestry?

[Luther Baker]

I'll chime in and say the template engine (html template and Java class
integration), the page pooling strategy and OO perspective that comes along
with it, native hibernate integration and the clever state management
between requests are all unique, out of the box and really help define the
Tapestry experience.

-Luther


On Sun, Apr 26, 2009 at 9:23 AM, Hugo Palma  wrote:

> I would like to add to what everyone else has pointed the excelent
> error reporting. I'm still to find another framework that has such
> self explanatory error reporting. It's a real time saver when trying
> to figure out why things aren't working.
>
> On Thu, Apr 23, 2009 at 7:12 PM, Sebastian Hennebrueder
>  wrote:
> > Hello,
> >
> > I am working on an article evaluating Tapestry 5 in details. The article
> is
> > part of an article series on my website http://www.laliluna.de on web
> > technologies and frameworks. Apart from a large article on technologies,
> > there is a detailed test of the Stripes Framework.
> >
> > One chapter in the evaluation is going to show features or concepts which
> > are very beautiful, unique or somehow special for this framework. In this
> > chapter, I would like to integrate
> > feedback from the community using the framework. I did this as well with
> > Stripes
> > (
> http://www.mail-archive.com/stripes-us...@lists.sourceforge.net/msg02294.html
> )
> >
> > This is why, I would like to ask you for your opinion.
> >
> > What is your favourite feature or concept of Stripes, what is unique as
> > compared to other things, what is an eye catcher?
> >
> > --
> > Best Regards / Viele Grüße
> >
> > Sebastian Hennebrueder
> > -
> > Software Developer and Trainer for Hibernate / Java Persistence
> > http://www.laliluna.de
> >
> >
> >
> >
> > -
> > 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: t:body

[Luther Baker]

On Tue, Mar 31, 2009 at 2:36 PM, Yancey Yeargan  wrote:

>
> Tapestry 5.1 does handle this correctly. I checked by changing ""
> to "" within the Layout.tml template of the quickstart example
> project and it worked as expected.



That is correct for 5.1.0.0, but this bug is specific to 5.1.0.1.

It is identified it as such in JIRA.

*Affects Version/s:* 5.1.0.1

-Luther

Re: t:body

[Luther Baker]

TAP5-615

Thanks,

-Luther


On Tue, Mar 31, 2009 at 1:57 PM, Howard Lewis Ship  wrote:

> Please add a bug; Tapestry should not be case sensitive about this
> (regardless about what the schema says). t:body and t:Body should be
> equivalent.  Tapestry 5.1 may already do this correctly.
>
> On Mon, Mar 30, 2009 at 9:28 AM, Luther Baker 
> wrote:
> > For some reason, my brain likes to keep a consistent capitalization
> strategy
> > ...
> >
> > So, I've grown accustomed to
> >
> > t:Parameter
> > t:ActionLink
> > t:PageLink
> >
> > and home/Index.tml, home/Index.java ... etc
> >
> > I just noticed that in my latest new project, I used  in a
> layout
> > template and I'm getting an error:
> >
> > Exception assembling root component of page home/Index: Unable to resolve
> > 'Body' to a component class name. Available component types: ActionLink,
> > AddRowLink, AjaxFormLoop, Any, BeanDisplay, BeanEditForm, BeanEditor,
> > Checkbox, DateField, Delegate, Errors, EventLink, ExceptionDisplay, Form,
> > FormFragment, FormInjector, Grid, GridCell, GridColumns, GridPager,
> > GridRows, If, Label, Layout, LinkSubmit, Loop, Output, OutputRaw,
> PageLink,
> > Palette, PasswordField, ProgressiveDisplay, PropertyDisplay,
> PropertyEditor,
> > Radio, RadioGroup, RemoveRowLink, RenderObject, Select, Submit,
> > SubmitNotifier, TextArea, TextField, TextOutput, Unless, Zone.
> >
> > If I switch to  ... all is well.
> >
> > Just thought this was interesting.
> >
> > -Luther
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

t:body

[Luther Baker]

For some reason, my brain likes to keep a consistent capitalization strategy
...

So, I've grown accustomed to

t:Parameter
t:ActionLink
t:PageLink

and home/Index.tml, home/Index.java ... etc

I just noticed that in my latest new project, I used  in a layout
template and I'm getting an error:

Exception assembling root component of page home/Index: Unable to resolve
'Body' to a component class name. Available component types: ActionLink,
AddRowLink, AjaxFormLoop, Any, BeanDisplay, BeanEditForm, BeanEditor,
Checkbox, DateField, Delegate, Errors, EventLink, ExceptionDisplay, Form,
FormFragment, FormInjector, Grid, GridCell, GridColumns, GridPager,
GridRows, If, Label, Layout, LinkSubmit, Loop, Output, OutputRaw, PageLink,
Palette, PasswordField, ProgressiveDisplay, PropertyDisplay, PropertyEditor,
Radio, RadioGroup, RemoveRowLink, RenderObject, Select, Submit,
SubmitNotifier, TextArea, TextField, TextOutput, Unless, Zone.

If I switch to  ... all is well.

Just thought this was interesting.

-Luther

Re: [T5.0.18] Class re-loading and eclipse debugger

[Luther Baker]

+1 @Robert to mvn jetty:run.

Portable to other IDEs as well as from command line.

-Luther





On Wed, Mar 18, 2009 at 12:57 PM, Hugues Narjoux wrote:

> "Are you on windows? what Maven plug-in version are you running? on Ubuntu
> it doesn't do this (there are some configuration options on the plug-in,
> try
> uncheck the ones you don't need)."
> No, the reason is we are running fancy home-brewed maven plugins processing
> zip files all around ... and this just takes hours 
>
> On Wed, Mar 18, 2009 at 6:07 PM, Peter Stavrinides <
> p.stavrini...@albourne.com> wrote:
>
> > Tomcat in the eclipse WTP can be very sensitive, I spent hours fiddling
> > with it, so if you can use Jetty then forget Tomcat. I just happen to use
> > both... Jetty mostly but sometimes Tomcat when I need to attach library
> > modules to debug and edit. Live reloading can almost work right in Tomcat
> > but not like Jetty, instead it does a partial reload (with some
> complaints
> > about resources being out of sync), nevertheless it can sort of work.
> >
> > >it runs the whole test-compile phase which in my case takes more
> > >than 5 minutes (don't ask why ;) ). Therefore I cannot use it for
> > >development.
> > Are you on windows? what Maven plug-in version are you running? on Ubuntu
> > it doesn't do this (there are some configuration options on the plug-in,
> try
> > uncheck the ones you don't need).
> >
> > regards,
> > Peter
> >
> >
> > - Original Message -
> > From: "Hugues Narjoux" 
> > To: "Tapestry users" 
> > Sent: Wednesday, 18 March, 2009 18:32:20 GMT +02:00 Athens, Beirut,
> > Bucharest, Istanbul
> > Subject: Re: [T5.0.18] Class re-loading and eclipse debugger
> >
> > But if you disable the automatic publishing, how would your modifications
> > be
> > updated  ? I tried it, even with manual publising and I still do not see
> my
> > the results of my update ...
> > I tried the maven jetty plugin like Borut suggested.It works just fine as
> > for class reloading. Except that every time you restart your server (mvn
> > jettty:run) it runs the whole test-compile phase which in my case takes
> > more
> > than 5 minutes (don't ask why ;) ). Therefore I cannot use it for
> > development.
> >
> >
> >
> >
> >
> > On Wed, Mar 18, 2009 at 3:39 PM, Peter Stavrinides <
> > p.stavrini...@albourne.com> wrote:
> >
> > > This is a pain, and has been an issue for years already... and
> > > unfortunately there is no end in site. There is a minor tweak though,
> WTP
> > > has an option (in Tomcat server properties dialog) select 'never
> publish
> > > automatically'
> > >
> > > regards,
> > > Peter
> > >
> > > - Original Message -
> > > From: "Thiago H. de Paula Figueiredo" 
> > > To: "Tapestry users" 
> > > Sent: Wednesday, 18 March, 2009 16:02:50 GMT +02:00 Athens, Beirut,
> > > Bucharest, Istanbul
> > > Subject: Re: [T5.0.18] Class re-loading and eclipse debugger
> > >
> > > On Wed, Mar 18, 2009 at 10:57 AM, Hugues Narjoux
> > >  wrote:
> > > > WTP was great here because it
> > > > would let you configure a deployment descriptor and automaticaly
> deploy
> > > and
> > > > re-assemble your webapp.
> > >
> > > I guess the problem is exactly the reassemble process. Many times,
> > > when using WTP in a Struts (aargh!) project, it
> > > wouldn't update the application correctly when I changed one class.
> > > Then I gave up. I never really deploy an application in development,
> > > just when really deploying to the production server, not wasting a lot
> > > of time with it.
> > >
> > > --
> > > Thiago
> > >
> > > -
> > > 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
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
>

Re: jetty and intellij

[Luther Baker]

Thanks for all the suggestions. I'll try these out Monday morning.

-Luther


On Sat, Mar 14, 2009 at 7:29 PM, Angelo Chen wrote:

>
> Hi,
>
> I have similar problem in 8.0, but when I upgraded to 8.1, it went away, my
> config is very simple, just add a Maven configuration, add jetty:run,
> that's
> all.
>
> I did not do this, but might worth trying:
>
> settings/compiler/resources patterns   add ?*.tml;
>
> actually when I switch to Maven config under Intellij, I never need to
> update resources patterns, it simply works.
>
>
>
> luther.baker wrote:
> >
> > I just fired up a new download of IntelliJ 8.1. Haven't used it much - so
> > pulled an existing Maven/Tapestry project and created a "configuration"
> > for
> > jetty:run.
> >
> > That works great. Through the settings, I also associated *.tml files
> with
> > an html filetype.
> >
> > Now, if I start the app all is well - but if I make a change to a *.tml
> > file
> > - the change is not showing up in the app unless I stop and restart. The
> > same goes for Java. I tested by changing a return class from a submit
> > handler - but the return page stayed the same.
> >
> > I know I must be missing a setting in IntelliJ - thoughts?
> >
> > -Luther
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/jetty-and-intellij-tp22499286p22518864.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: Q : IF component in tapestry 5 ?

[Luther Baker]

I believe that setting your chart type Strings in a SUBMIT event handler
without persisting them - effectively does nothing for you. They will be
reset to null before the successive page sees them.

Unless you set your chart type in a "PRE" event of the successive page
(onActivate ...) - I believe you'll need to @Persist your chart types ..

Something like:

@Persist
 @Property
private String dailyChart, monthlyChart, yearlyChart;

Make sure @Persist and @Property apply to all the relevant Strings.

-Luther



On Sat, Mar 14, 2009 at 1:26 PM, Ulrich Stärk  wrote:

> The test will be true if the provided test returns true or in case of an
> object return type that object is not null.
>
> Uli
>
> Alex Kotchnev schrieb:
>
>  w/o looking at the docs, my impression is that the 'test' attribute of
>> t:if expects a boolean value. Neither of daily,monthly,and yearly
>> chart props are boolean.
>>
>> On 3/14/09, dwi ardi irawan  wrote:
>>
>>> guys, i'm so stress with "if" komponent. how to use it
>>> here's my code
>>>
>>>
>>> .tml
>>> ===
>>>
>>> 
>>>
>>>
>>>AAA
>>>
>>>
>>>
>>>
>>>BBB
>>>
>>>
>>>
>>>CCC
>>>
>>>
>>> =
>>>
>>> .java
>>> =
>>>
>>>   @Persist
>>>private ChartType chartType;
>>>
>>>public ChartType getChartType() {
>>>return chartType;
>>>}
>>>
>>>@Property
>>>private String dailyChart, monthlyChart, yearlyChart;
>>>
>>>   Object onSuccessFromChartForm(){
>>>
>>>if(chartType==ChartType.DAILY){
>>>dailyChart = "D";
>>>monthlyChart = null;
>>>yearlyChart = null;
>>>}else if (chartType==ChartType.MONTHLY) {
>>>dailyChart = null;
>>>monthlyChart = "M";
>>>yearlyChart = null;
>>>}else if (chartType==chartType.YEARLY) {
>>>dailyChart = null;
>>>monthlyChart = null;
>>>yearlyChart = "Y";
>>>}
>>>
>>>
>>>
>>> if we look the code above, it should work but it doesn't
>>> when i choose "Daily" on select menu that means dailyChart property will
>>> become "D" and it should render this block and output "AAA"
>>> 
>>>AAA
>>>
>>>
>>> is there something wrong wih my code or my perception of if component in
>>> tapestry 5
>>>
>>>
>>> thnx u
>>>
>>> dwi ardi irawan - 'penyihirkecil'
>>> http://www.dwiardiirawan.com 
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: jetty and intellij

[Luther Baker]

Hey Howard,

> I know I must be missing a setting in IntelliJ - thoughts?

Who's complaining? My original post asked for thoughts ...

The majority of my second post was was in  brackets. Don't take that
too too seriously - your response to my original question - with another
question was essentially asking "well, why would you want to do a thing like
that?" ... so, I elaborated :) Again - it was in brackets so you'd know I
was preaching, big ideals, big picture stuff ...

No insult taken - I didn't know Maven bothered you so. We've not had to
tweak, refactor or worry about plugins with Maven. I just type mvn jetty:run
and everything downloads and has worked well. Luntbuild, Cruise Conrol,
Netbeans, Eclipse and IntelliJ all run from the same project build and been
doing so without custom tweaks for the past year.

In this specific case, I was just looking for the magic flag inside of
IntelliJ to push changes out ... not complaining about it.

-Luther



On Fri, Mar 13, 2009 at 4:08 PM, Howard Lewis Ship  wrote:

> Ok, then, why are you then complaining on the Tapestry mailing list
> about your Maven stuff not working correctly?  I don't mean to be
> insulting ... I'm just saying that the myth of Maven seems to far
> outdistance the reality.  It's always just one more little tweak, one
> more refactoring, one more update to a plugin ... and it never ends!
>
> I think the core idea: versioned dependencies with transitive
> relationships, is very, very good. I just want to get away from using
> the build portion.
>
> On Fri, Mar 13, 2009 at 11:48 AM, Luther Baker 
> wrote:
> > Thanks Richard. That helps and I'll take a look ...
> >
> > 
> > One build process. Cross platform. IDE agnostic. That is our motto.
> >
> > Our continuous integration / build process is IDE agnostic. Maven builds,
> > runs and tests the app on Unix servers, windows boxes and Macs.
> > Additionally, NetBeans has native support for Maven projects. Most of our
> > team uses Eclipse and the Maven plugin works without any Eclipse specific
> > config. I fired up IntelliJ and the app built and deployed right out of
> the
> > box ... I'm just wondering where the flag is to automatically update apps
> > running via that plugin.
> >
> > I can/will look at the IDE specific plugin - but it is not my first
> choice -
> > and it's alot more than just *simplicity*.
> >
> > By leveraging Maven, configuration and classpaths are always built the
> same
> > way - dev, test and prod builds (cruise control, luntbuild, etc) and can
> be
> > built and deployed without IDE dependencies. It forms the baseline and
> > everything else works around that foundation. As soon as I have to custom
> > configure Eclipse WTP, MyEclipse or IntelliJ specific Jetty plugins, I
> have
> > to setup the IDE with IDE specific classpaths, etc that don't always work
> > out of the box in the other builds. Maven takes care of all of that for
> us.
> >
> > I've developed with Emacs and Maven on the command line. NetBeans opens
> > Maven projects natively. Maven and Eclipse work almost seamlessly
> (updating
> > classes as source changes). Out of the box, IntelliJ works for the most
> part
> > if I restart the app manually - but I thought I'd check to see if there
> were
> > a flag to auto-restart on changes to source.
> >
> > If one of these IDE editors need special handling, sobeit - but it isn't
> the
> > first thing I'd try or want to do since the general process around Maven
> > works so well. It might be considered forward (or backward) thinking 
> > but alot of it works now - and it is quite simple to setup. Just download
> > and unzip Maven :)
> > 
> >
> > Honestly, once you embrace and use it regularly, Maven becomes very
> > powerful. IDEs become arbitrary since all of them import or open Maven
> > projects. Continuous Integration, Testing and Standard Build processes
> can
> > now define project structure and lifecycle - and IDEs simply adhere to it
> -
> > not the other way around.
> >
> > -Luther
> >
> >
> >
> >
> > On Fri, Mar 13, 2009 at 12:55 PM, Richard Clark 
> wrote:
> >
> >> P.S. http://wiki.apache.org/tapestry/Tapestry5_Run_Jetty_From_IDEA
> >>
> >> (5 minutes and 2 page loads later)
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: jetty and intellij

[Luther Baker]

Thanks Richard. That helps and I'll take a look ...


One build process. Cross platform. IDE agnostic. That is our motto.

Our continuous integration / build process is IDE agnostic. Maven builds,
runs and tests the app on Unix servers, windows boxes and Macs.
Additionally, NetBeans has native support for Maven projects. Most of our
team uses Eclipse and the Maven plugin works without any Eclipse specific
config. I fired up IntelliJ and the app built and deployed right out of the
box ... I'm just wondering where the flag is to automatically update apps
running via that plugin.

I can/will look at the IDE specific plugin - but it is not my first choice -
and it's alot more than just *simplicity*.

By leveraging Maven, configuration and classpaths are always built the same
way - dev, test and prod builds (cruise control, luntbuild, etc) and can be
built and deployed without IDE dependencies. It forms the baseline and
everything else works around that foundation. As soon as I have to custom
configure Eclipse WTP, MyEclipse or IntelliJ specific Jetty plugins, I have
to setup the IDE with IDE specific classpaths, etc that don't always work
out of the box in the other builds. Maven takes care of all of that for us.

I've developed with Emacs and Maven on the command line. NetBeans opens
Maven projects natively. Maven and Eclipse work almost seamlessly (updating
classes as source changes). Out of the box, IntelliJ works for the most part
if I restart the app manually - but I thought I'd check to see if there were
a flag to auto-restart on changes to source.

If one of these IDE editors need special handling, sobeit - but it isn't the
first thing I'd try or want to do since the general process around Maven
works so well. It might be considered forward (or backward) thinking 
but alot of it works now - and it is quite simple to setup. Just download
and unzip Maven :)


Honestly, once you embrace and use it regularly, Maven becomes very
powerful. IDEs become arbitrary since all of them import or open Maven
projects. Continuous Integration, Testing and Standard Build processes can
now define project structure and lifecycle - and IDEs simply adhere to it -
not the other way around.

-Luther




On Fri, Mar 13, 2009 at 12:55 PM, Richard Clark  wrote:

> P.S. http://wiki.apache.org/tapestry/Tapestry5_Run_Jetty_From_IDEA
>
> (5 minutes and 2 page loads later)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

jetty and intellij

[Luther Baker]

I just fired up a new download of IntelliJ 8.1. Haven't used it much - so
pulled an existing Maven/Tapestry project and created a "configuration" for
jetty:run.

That works great. Through the settings, I also associated *.tml files with
an html filetype.

Now, if I start the app all is well - but if I make a change to a *.tml file
- the change is not showing up in the app unless I stop and restart. The
same goes for Java. I tested by changing a return class from a submit
handler - but the return page stayed the same.

I know I must be missing a setting in IntelliJ - thoughts?

-Luther

Re: T5: How to load image Asset from filesystem?

[Luther Baker]

Great example - similar to an example on the Wiki ...

Note that 'createActionLink' was deprecated ...

http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/ComponentResources.html#createActionLink(java.lang.String,%20boolean,%20java.lang.Object..
.)

*Deprecated.* *Use createEventLink(String,
Object[])instead
*
-Luther



On Thu, Mar 12, 2009 at 9:42 PM, Daniel Jones  wrote:

>
> Hi Peter,
>
> I'm using nabble to post and it seems to have stripped out the img tag.
>
> you need an img tag in your template and set the src attribute to
> ${imagePath}
>
> img src="${imagePath}"
>
> Hope this helps,
> Daniel
>
>
> Peter Kanze wrote:
> >
> > Hi Daniel,
> >
> > Thanks for your example. I tried this one, but the Object onImage is
> never
> > called when the page loads.
> > I am using Tapestry 5.1. The code is equal to your example.
> >
> > What could I do wrong?
> >
> > regards,
> > Peter
> >
> > On Thu, Mar 12, 2009 at 10:54 AM, Daniel Jones 
> wrote:
> >
> >>
> >> PAGE CLASS
> >>
> >> inject component resources so that you can create an action link
> >>@Inject
> >>private ComponentResources mComponentResources;
> >>
> >> when the path is requested by the template, create and return an action
> >> link
> >>public Link getImagePath() {
> >>return mComponentResources.createActionLink("image",
> >> false,
> >> mItem.getID());
> >>}
> >>
> >> handle this action link
> >>public Object onImage(long pID) {
> >> "StreamResponseBuilder" is a class that I have implemented, it basically
> >> figures out what image to served based on
> >> the id passed in the context and then gets an "InputStream" for the
> image
> >> file on disk and creates and returns a "StreamResponse", so essentially
> >> you
> >> want this action handler to return a "StreamResponse" of the image you
> >> want
> >> to display.
> >>return StreamResponseBuilder.getItemImage(pID);
> >>}
> >>
> >> PAGE TEMPLATE
> >>
> >> ${imagePath}
> >>
> >> Hope this helps
> >> Regards,
> >> Daniel
> >>
> >>
> >>
> >> Peter Kanze wrote:
> >> >
> >> > Hello
> >> >
> >> > I want to load images from the filesystem, like for example
> >> > D:/category/1/products/55/thumb.jpg
> >> >
> >> > So the file path is dynamic and is based on the categoryId and the
> >> > productId.
> >> >
> >> > How can I load such an image into my webpage using a Tapestry Asset?
> >> > This looks like a common usecase to me, but I couldn't find any info
> >> about
> >> > it.
> >> >
> >> > Has somebody already done this? And could he/she show me some code
> >> > examples?
> >> > Any help is welcome!
> >> >
> >> > Thanks,
> >> > Peter
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/T5%3A-How-to-load-image-Asset-from-filesystem--tp22433419p22471474.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
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/T5%3A-How-to-load-image-Asset-from-filesystem--tp22433419p22489180.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: [T5] 5.1.0.1 RC, rendering of some views produces stacktrace

[Luther Baker]

One suggestion ... download and attach the source.

You could step through from the beginning of the request (can be tricky to
trace from the beginning with all the Javassist).

Or - at a minimum, you could jump to AbstractMarkupModel.java:94 and work
your way from there.

-Luther




On Thu, Mar 12, 2009 at 4:19 PM, Howard Lewis Ship  wrote:

> 5.1.0.1 is not a release candidate. It's out there for exposure as an
> alpha release (the vote isn't even completed yet!)
>
> It looks like an issue with how null attributes are treated; assigning
> an attribute (of a DOM Element) the value null is supposed to remove
> the attribute entirely but it looks like that's not happening,
> resulting in a later NPE while rendering.
>
> On Wed, Mar 11, 2009 at 2:21 AM, Ville Virtanen
>  wrote:
> >
> > Hi,
> >
> > We are constantly getting this stacktrace on some of our views. Nothing,
> and
> > I mean nothing else is visible. The normal T5 error page doesn't come up
> > etc. Only this stacktrace. Using 5.1.0.1-20090305.090208-13 everything
> works
> > ok.
> >
> > Does anyone know how to trace this or dig deeper?
> >
> >  - Ville
> >
> > java.lang.NullPointerException
> >at
> >
> org.apache.tapestry5.dom.AbstractMarkupModel.encodeQuoted(AbstractMarkupModel.java:94)
> >at
> > org.apache.tapestry5.dom.Element$Attribute.render(Element.java:60)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:348)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at
> > org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870)
> >at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386)
> >at org.apache.tapestry5.dom.Document.toMarkup(Document.java:163)
> >at org.apache.tapestry5.dom.Node.toMarkup(Node.java:80)
> >at
> >
> org.apache.tapestry5.internal.services.MarkupWriterImpl.toMarkup(MarkupWriterImpl.java:57)
> >at
> >
> org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:67)
> >at
> >
> $PageResponseRenderer_11ff4c79641.renderPageResponse($PageResponseRenderer_11ff4c79641.java)
> >at
> >
> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:63)
> >at
> >
> org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:1920)
> >at
> >
> $PageRenderRequestHandler_11ff4c79642.handle($PageRenderRequestHandler_11ff4c79642.java)
> >at
> >
> $PageRenderRequestHandler_11ff4c7962d.handle($PageRenderRequestHandler_11ff4c7962d.java)
> >at
> >
> org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
> >at
> >
> $ComponentRequestHandler_11ff4c79632.handlePageRender($ComponentRequestHandler_11ff4c79632.java)
> >at
> >
> org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
> >at $Dispatcher_11ff4c79634.dispatch($Dispatcher_11ff4c79634.java)
> >at $Dispatcher_11ff4c7962a.dispatch($Dispatcher_11ff4c7962a.java)
> >at
> >
> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:249)
> >at
> >
> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
> >at
> > $RequestHandler_11ff4c7962b.service($RequestHandle

Re: Index Pages, 404s and Redirects

[Luther Baker]

Is there anyway you can leverage web.xml error handling for this?



...

404
errors/FourOhFour.tml


java.lang.Throwable
errors/throwable.tml

...



IE: catch *specific *exceptions (what is thrown for missing pages, etc) and
push them to a Tapestry page that implements the logic you want? Please
don't take the example literally :) i.e. handle whatever exceptions and
forward to whatever pages would make sense.

-Luther



On Thu, Mar 12, 2009 at 3:28 PM, Geoffrey Wiseman <
geoffrey.wise...@gmail.com> wrote:

> On Wed, Mar 11, 2009 at 7:33 PM, nillehammer
>  wrote:
>
> > Tapestry's Delegate-Component
> > (
> >
> http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Delegate.html
> > )
> > to show an error message.
> >
>
> I guess I'm still processing this -- how would a delegate component be of
> help to me here?
> It's a little awkward to have each index template have a top-level
> conditional:
> - if this is a 'not found' then show an error
> - else show the actual page template
>
> I dunno how often I'd be repeating this pattern - perhaps very rarely.  If
> it came up more than a couple times, I'd probably live with the
> /pagenotfound approach just to avoid the duplication.  I suppose I could
> even use a layout to get around the duplication.  Anyway -- ultimately, I
> think I'm probably fighting against the grain a little too hard and should
> probably just live with the /start URL and accept that Tapestry owns the
> URL
> structure more than I'd necessarily choose.  ;)
>
>  - Geoffrey
> --
> Geoffrey Wiseman
> http://www.geoffreywiseman.ca/
>

Re: img tag (src)

[Luther Baker]

Got it! thanks to both of you and the examples.

Wow - onActivate can return an Object :) and nice to know about
ComponentResources.

-Luther





On Wed, Mar 11, 2009 at 10:15 AM, Elmer Smith wrote:

> I have a component based off of the example Thiago mentions.  The just
> of it is:
>
>  - a page ViewImage that has an activation context of a d/b related ID
>  - that pages onActivate returns a StreamResponse
>  - the stream response is created by loading bytes from the d/b using
> the ID passed in the activation context
>  - a component that uses a template with an  tag
>  - the component provides a link to the ViewImage page; the link can be
> constructed to ask the containing component (or page) to provide the
> byte stream or it will provide a default
>
> I use this all over to render images that are stored in the database.
>
> Hope that helps,
> Elmer
>
> -Original Message-
> From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com]
> Sent: Wednesday, March 11, 2009 9:52 AM
> To: Tapestry users
> Subject: Re: img tag (src)
>
> Maybe
> http://wiki.apache.org/tapestry/Tapestry5HowToCreateASimpleGraphComponen
> t
> is an example that can be adapted to what you need.
>
> > So, from a different perspective, what I really want in my page is
> somethin like
> > Object onRender()
> > {
> >   StreamResponse = ...
> >   
> >   return streamResponse;
> > }
>
> Instead of onRender(), use onActivate(). ;)
>
> --
> Thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> This message (including any attachments) is intended only for the use of
> the individual or entity to whom it is addressed and may contain information
> that is non-public, proprietary, privileged, confidential, and exempt from
> disclosure under applicable law or may constitute attorney work product. If
> you are not the intended recipient, you are hereby notified that any use,
> dissemination, distribution, or copying of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately by telephone and (i) destroy this message if a facsimile or
> (ii) delete this message immediately if an electronic communication.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: img tag (src)

[Luther Baker]

I was hoping to wake up to a solution/suggestion :)

Anyone?

So, from a different perspective, what I really want in my page is something
like


Object onRender()
{
   StreamResponse = ...
   
   return streamResponse;
}


where I can simply return the blog - just like onActionFromId ... type
handlers. The problem here for me is ...

what event to use when rendering a url the browser requests (like ) and how to get a binary response back and cease the
rest of the events..

Dare I try

Object pageAttached()
{
 ...
}


Hope that makes sense. Simplistically, I'm just trying to render an image
when the page is requested.

Were this stuts, I do this in the execute method of the action but with the
stages Tapestry has, I'm sure I need to think about it subtley differently.
I just haven't done something like this when RENDERING the page - only on
ACTION from the page - etc.

I'll keep thinking about it - maybe I am just missing it. Thanks,

-Luther



On Wed, Mar 11, 2009 at 1:25 AM, Luther Baker  wrote:

> So I've embedded an img tag as follows: 
>
> The url "image/Get/1" invokes page "image/Get" with an activation context
> of "1". The *.java onActivate handler loads the image from Hibernate. The
> corresponding *.tml page only has one component on it of which takes a
> @Parameter of type Image ... which the page successfully gives it.
>
> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> 
> 
>
> And hopefully, the ImageStream component attempts to render itself --- does
> this sound correct so far?
>
> My problem is - how does the component render binary data? IE: component
> render methods can take 0 or 1 argument, a MarkupWriter ... which doesn't
> have a binary output method. And if I try to be slick and change the render
> method signature to
>
> Object beginRender()
>
> I predictably get the error:
>
> "The return value from a render phase event method was not compatible the
> expected return type of java.lang.Boolean. You should change the method to
> return the correct type."
>
> So I think I'm back to the same question, "is there a way I can return
> binary information as part of a page or component's rendering lifecycle?"
> i.e.: in response to a GET.
>
> I can definitely do it onAction, onSuccess, etc since those methods can
> return Object ... streams, pages, etc. But what about BEFORE the user takes
> such action ... in the rendering cycle or as a simple response to a GET.
> Those render lifecycle methods seem to return boolean.
>
> Does that question make sense? Thanks,
>
> -Luther
>
>
>
>
>
> On Tue, Mar 10, 2009 at 5:06 PM, Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> Em Tue, 10 Mar 2009 16:57:11 -0300, Luther Baker 
>> escreveu:
>>
>>  Am I'm looking for a render method that returns an Object - and stops the
>>> rest of the lifecycle?
>>>
>>
>> I would try to create a component instead. It is a more reusable solution.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/thiago
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>

Re: img tag (src)

[Luther Baker]

So I've embedded an img tag as follows: 

The url "image/Get/1" invokes page "image/Get" with an activation context of
"1". The *.java onActivate handler loads the image from Hibernate. The
corresponding *.tml page only has one component on it of which takes a
@Parameter of type Image ... which the page successfully gives it.

http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>



And hopefully, the ImageStream component attempts to render itself --- does
this sound correct so far?

My problem is - how does the component render binary data? IE: component
render methods can take 0 or 1 argument, a MarkupWriter ... which doesn't
have a binary output method. And if I try to be slick and change the render
method signature to

Object beginRender()

I predictably get the error:

"The return value from a render phase event method was not compatible the
expected return type of java.lang.Boolean. You should change the method to
return the correct type."

So I think I'm back to the same question, "is there a way I can return
binary information as part of a page or component's rendering lifecycle?"
i.e.: in response to a GET.

I can definitely do it onAction, onSuccess, etc since those methods can
return Object ... streams, pages, etc. But what about BEFORE the user takes
such action ... in the rendering cycle or as a simple response to a GET.
Those render lifecycle methods seem to return boolean.

Does that question make sense? Thanks,

-Luther




On Tue, Mar 10, 2009 at 5:06 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 10 Mar 2009 16:57:11 -0300, Luther Baker 
> escreveu:
>
>  Am I'm looking for a render method that returns an Object - and stops the
>> rest of the lifecycle?
>>
>
> I would try to create a component instead. It is a more reusable solution.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

img tag (src)

[Luther Baker]

If I am storing an image in the database - and would like to display it in
response to

   

I've implemented the following examples:

http://wiki.apache.org/tapestry/Tapestry5HowToStreamAnExistingBinaryFile
http://wiki.apache.org/tapestry/Tapestry5HowToCreateADynamicPDF

and I've got that work fine with something like

Object onActionFromX()
{
}

but what about rendering this image inline? I think I would want to
implement a render lifecycle method ... ? Does that sound correct?

It seems that these all return boolean -
http://tapestry.apache.org/tapestry5/guide/rendering.html -

Am I'm looking for a render method that returns an Object - and stops the
rest of the lifecycle?

Thanks in advance,

-Luther

Re: cross field validation with empty fields

[Luther Baker]

Thanks Elmer. And ugh ... sorry for the previous typo "@Elmo",

(Cool Beans was @Jonathan for his Bean example - but got out of order in
this thread).

-Luther



On Mon, Mar 9, 2009 at 1:02 PM, Luther Baker  wrote:

> Cool beans. Literally :)
>
>
>
> On Mon, Mar 9, 2009 at 12:49 PM, Jonathan Barker <
> jonathan.theit...@gmail.com> wrote:
>
>> My experience was with 4.0.
>>
>> You want to look at the ValidationDelegate.
>>
>> @Bean
>> public abstract ValidationDelegate getDelegate();
>>
>> // set up as listener for form
>> public void onSubmit(IRequestCycle cycle){
>>   ValidationDelegate = getDelegate();
>>   (if (delegate.getHasErrors())
>>   return;
>>   if (StringUtils.isBlank(fieldA) &&
>> (StringUtils.isBlank(fieldB)||StringUtils.isBlank(fieldC))){
>>  delegate.setFormComponent(null);
>>  delegate.record("Cross form vaildation failed");
>>  return;
>>   } else {
>>  cycle.activate("SomeOtherPage");
>>   }
>>
>> )
>>
>>
>>
>>
>>
>>
>> On Mon, Mar 9, 2009 at 7:29 AM, Ivano Luberti 
>> wrote:
>> >
>> > Sorry to ask for this again, but I have seen no answer.
>> > I will get no answer again I will stop asking for this, of course.
>> >
>> > TIA
>> >
>> > 
>> > Hello, we are using T4.1
>> > We have to validate a form and we don't want to do it client side.
>> > Let say we have three text fields.
>> > The validation should implement the following rule:
>> > if (fielda="") && (fieldb="" || fieldc="")
>> >  then throw new Exception("");
>> >
>> > The problem is that we cannot link the validation to neither field
>> > because they can be empty and the custom validator we are trying to
>> > implement is nevere called if the field is empty.
>> > We tried to  follow the Identity validator but it is also not called
>> > when the field to which is associated is empty.
>> >
>> > Is there another way to accomplish cross field validation ?
>> >
>> > It seems to us that in T4.1  lacks a validator attribute for the form
>> > component.
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> > For additional commands, e-mail: users-h...@tapestry.apache.org
>> >
>>
>>
>>
>> --
>> Jonathan Barker
>> ITStrategic
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>

Re: cross field validation with empty fields

[Luther Baker]

Cool beans. Literally :)


On Mon, Mar 9, 2009 at 12:49 PM, Jonathan Barker <
jonathan.theit...@gmail.com> wrote:

> My experience was with 4.0.
>
> You want to look at the ValidationDelegate.
>
> @Bean
> public abstract ValidationDelegate getDelegate();
>
> // set up as listener for form
> public void onSubmit(IRequestCycle cycle){
>   ValidationDelegate = getDelegate();
>   (if (delegate.getHasErrors())
>   return;
>   if (StringUtils.isBlank(fieldA) &&
> (StringUtils.isBlank(fieldB)||StringUtils.isBlank(fieldC))){
>  delegate.setFormComponent(null);
>  delegate.record("Cross form vaildation failed");
>  return;
>   } else {
>  cycle.activate("SomeOtherPage");
>   }
>
> )
>
>
>
>
>
>
> On Mon, Mar 9, 2009 at 7:29 AM, Ivano Luberti 
> wrote:
> >
> > Sorry to ask for this again, but I have seen no answer.
> > I will get no answer again I will stop asking for this, of course.
> >
> > TIA
> >
> > 
> > Hello, we are using T4.1
> > We have to validate a form and we don't want to do it client side.
> > Let say we have three text fields.
> > The validation should implement the following rule:
> > if (fielda="") && (fieldb="" || fieldc="")
> >  then throw new Exception("");
> >
> > The problem is that we cannot link the validation to neither field
> > because they can be empty and the custom validator we are trying to
> > implement is nevere called if the field is empty.
> > We tried to  follow the Identity validator but it is also not called
> > when the field to which is associated is empty.
> >
> > Is there another way to accomplish cross field validation ?
> >
> > It seems to us that in T4.1  lacks a validator attribute for the form
> > component.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
>
>
>
> --
> Jonathan Barker
> ITStrategic
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: cross field validation with empty fields

[Luther Baker]

Oops sorry @Elmer, I mistyped your name in the previous post and meant
@Ivano.

Also, @Elmo, I think you're suggestion was perfect! but it looked like T5
code.

Shows how little I know about T4 though. Sorry - I think your post was right
on if all those annotations and events were in T4.

-Luther




I meant my latest suggestion to be @Ivano

On Mon, Mar 9, 2009 at 12:44 PM, Luther Baker  wrote:

> That's a fine point to clarify.
>
> My underlying suggestion wasn't meant to imply which was the correct,
> well-defined event to handle. This is the second post ... no luck/help so
> far? ... So my suggestion is that, if all else fails, you can do MANUAL
> validation in, if nothing else, the MAIN event handler. Again, I didn't mean
> to focus on the actual event as much as the ability to MANUALLY validate and
> still send back field specific error messages.
>
> To Thiago's point, if taken too literally, yes, the example could be
> misleading. But it is a minor point. The login example on the Tapestry
> website happens to do AUTHENTICATION in the SUCCESS handler (oddly, as part
> of a validation example) - and so it is a nice concrete example to send
> around - but lest I am misunderstood, it is the general concept I'm trying
> to shed some light on ... not whether it is authentication or validation or
> onValidate or onSuccess.
>
> FWIW: since no one posted any response to the poster's original question
> (per the poster) and this is the 2nd time he's asked - I assumed that what
> he is doing must be out of the ordinary. I do nto know T4 and the fact that
> (per the user) 'null' values in the form skipped validation - made me wonder
> if the onValidate event was being skipped (as a part of T4).
>
> @Elmer: so conceptually, you could start by implementing this validation
> MANUALLY in the MAIN method and work backwards from there. IE: start with
> something you KNOW fires and keep moving that logic backwards until you get
> it into a true, validation handler if at all possible. It is an iterative,
> workable approach eh?
>
> But to Thiago's point, if T4 has specific validation events/handlers and
> those fire in all cases - by all means, implement this logic there (dont'
> need to start in the main event handler). You can still follow the general
> logic/structure of the authentication example I linked to.
>
> Please excuse the rambling here ... hope the clarification was helpful.
>
> -Luther
>
>
>
>
> On Mon, Mar 9, 2009 at 12:15 PM, Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> Em Mon, 09 Mar 2009 14:08:43 -0300, Luther Baker 
>> escreveu:
>>
>>  Oddly enough, it is NOT the validation handler I want to bring to your
>>> attention to (here on this validation.html page :) and again, obviously,
>>> this is Tapestry 5 - but notice how authentication is done in the SUCCESS
>>> handler.
>>>
>>
>> Authentication is not validation. They're different things. Authentication
>> is made at onSuccess() because it is only made after the form validation (ie
>> the values of login and password are valid for that field). And you should
>> do validation at onValidate().
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/thiago
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>

Re: cross field validation with empty fields

[Luther Baker]

That's a fine point to clarify.

My underlying suggestion wasn't meant to imply which was the correct,
well-defined event to handle. This is the second post ... no luck/help so
far? ... So my suggestion is that, if all else fails, you can do MANUAL
validation in, if nothing else, the MAIN event handler. Again, I didn't mean
to focus on the actual event as much as the ability to MANUALLY validate and
still send back field specific error messages.

To Thiago's point, if taken too literally, yes, the example could be
misleading. But it is a minor point. The login example on the Tapestry
website happens to do AUTHENTICATION in the SUCCESS handler (oddly, as part
of a validation example) - and so it is a nice concrete example to send
around - but lest I am misunderstood, it is the general concept I'm trying
to shed some light on ... not whether it is authentication or validation or
onValidate or onSuccess.

FWIW: since no one posted any response to the poster's original question
(per the poster) and this is the 2nd time he's asked - I assumed that what
he is doing must be out of the ordinary. I do nto know T4 and the fact that
(per the user) 'null' values in the form skipped validation - made me wonder
if the onValidate event was being skipped (as a part of T4).

@Elmer: so conceptually, you could start by implementing this validation
MANUALLY in the MAIN method and work backwards from there. IE: start with
something you KNOW fires and keep moving that logic backwards until you get
it into a true, validation handler if at all possible. It is an iterative,
workable approach eh?

But to Thiago's point, if T4 has specific validation events/handlers and
those fire in all cases - by all means, implement this logic there (dont'
need to start in the main event handler). You can still follow the general
logic/structure of the authentication example I linked to.

Please excuse the rambling here ... hope the clarification was helpful.

-Luther



On Mon, Mar 9, 2009 at 12:15 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Mon, 09 Mar 2009 14:08:43 -0300, Luther Baker 
> escreveu:
>
>  Oddly enough, it is NOT the validation handler I want to bring to your
>> attention to (here on this validation.html page :) and again, obviously,
>> this is Tapestry 5 - but notice how authentication is done in the SUCCESS
>> handler.
>>
>
> Authentication is not validation. They're different things. Authentication
> is made at onSuccess() because it is only made after the form validation (ie
> the values of login and password are valid for that field). And you should
> do validation at onValidate().
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: cross field validation with empty fields

[Luther Baker]

I'm not familiar worth T4.1 but it seems to me that you could put something
in the submit or success handler that validates.

Take a look here -
http://tapestry.apache.org/tapestry5/guide/validation.html and find the
following snippet:

public class Login
{


*String onSuccess()
{
if (!authenticator.isValid(userName, password))
{
form.recordError(passwordField, "Invalid user name or
password.");
return null;
}*

return "PostLogin";
}


Oddly enough, it is NOT the validation handler I want to bring to your
attention to (here on this validation.html page :) and again, obviously,
this is Tapestry 5 - but notice how authentication is done in the SUCCESS
handler. I would try to do something similar (albeit validation) to look at
the fields you are processing.

It'd be manual ... but notice here - an error is returned and associated
with T5 fields ...

Again - you'll need to find T4s parallel.

-Luther



On Mon, Mar 9, 2009 at 10:04 AM, Elmer Smith wrote:

> Ivano,
>
> I'm pretty sure what you want to do is provide an onValidate method in
> your page class.  That method gets called expressly for doing more
> complicated validation.  If you have more than one form, you'll have to
> further specify it e.g. onValidateFromMyFormName (or use @OnEvent
> annotation).  Here's some abbreviated code:
>
> @InjectComponent("fielda")
> private TextField fieldaComponent;
>
> @InjectComponent
> private Form formComponent;
> ...
>
> Object onValidate() {
>If (fielda == null)
>formComponent.recordError(fieldaComponent, "Example error
> message for fielda");
>
>if (fielda=="") && (fieldb=="" || fieldc=="")
>   throw new RuntimeException();
>
>return null;  // this will keep you on the same page
>
> //return NewPage.class; // this will goto the NewPage page, etc.
> etc.
> }
>
> You may just want to provide a validation message.  I've shown an
> example using fielda in the preceding code.
>
> Read the docs on the Form component, and see the examples in the user
> guide.
>
> Cheers
> -Original Message-
> From: Ivano Luberti [mailto:lube...@archicoop.it]
> Sent: Monday, March 09, 2009 8:30 AM
> To: Tapestry users
> Subject: cross field validation with empty fields
>
> Sorry to ask for this again, but I have seen no answer.
> I will get no answer again I will stop asking for this, of course.
>
> TIA
>
> 
> Hello, we are using T4.1
> We have to validate a form and we don't want to do it client side.
> Let say we have three text fields.
> The validation should implement the following rule:
> if (fielda="") && (fieldb="" || fieldc="")
>  then throw new Exception("");
>
> The problem is that we cannot link the validation to neither field
> because they can be empty and the custom validator we are trying to
> implement is nevere called if the field is empty.
> We tried to  follow the Identity validator but it is also not called
> when the field to which is associated is empty.
>
> Is there another way to accomplish cross field validation ?
>
> It seems to us that in T4.1  lacks a validator attribute for the form
> component.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> This message (including any attachments) is intended only for the use of
> the individual or entity to whom it is addressed and may contain information
> that is non-public, proprietary, privileged, confidential, and exempt from
> disclosure under applicable law or may constitute attorney work product. If
> you are not the intended recipient, you are hereby notified that any use,
> dissemination, distribution, or copying of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately by telephone and (i) destroy this message if a facsimile or
> (ii) delete this message immediately if an electronic communication.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

jetty, tapestry and realms

[Luther Baker]

Do Maven, Jetty, Realms and Tapestry play nice out of the box?

App works just fine without any of the following - but after adding the
below, I'm getting an error and I'm not sure what I'm missing. The error
sure looks like it is *partly* working ... "FORBIDDEN" but the browser is
NOT prompting me with a browser popup defined by
BASIC.

Thoughts?

Thanks,

-Luther




HTTP ERROR 403

Problem accessing /notebook/Home. Reason:

FORBIDDEN

--
*Powered by Jetty://




*
*web.xml*



basic-notebook-auth
/*
GET
POST



NONE



BASIC
*notebook-realm*



*pom.xml*

  
org.mortbay.jetty
maven-jetty-plugin

  notebook
  

  9090
  6

  
  

  *notebook-realm*
  
src/main/config/jetty/notebook-hash-user-realm.properties



*src/main/config/jetty/notebook-hash-user-realm.properties*

#
# This file defines users passwords and roles for a HashUserRealm
#
# The format is
#  : [, ...]
#
# Passwords may be clear text, obfuscated or checksummed.  The class
# org.mortbay.util.Password should be used to generate obfuscated
# passwords or password checksums
#
testuser: secretpassword

Re: generics and pages, components and edit blocks

[Luther Baker]

Ok, I'll bite :)

http://www.jroller.com/WarnerOnstine/entry/tapestry_future_adoption_redux


One shining point came from Howard himself --

"Further, the design of Tapestry 5 was created specifically to make it
possible to continue adding features without breaking backwards
compatibility going forward. There will not need to be a Tapestry 6."



On Sun, Mar 8, 2009 at 9:41 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Sun, 08 Mar 2009 23:35:44 -0300, Luther Baker 
> escreveu:
>
>  Yes.
>>
>> Maybe Tapestry 6 :)
>>
>
> "Tapestry 6" has a history of controversy and trolling. As it's already
> 23:38 PM here in Belo Horizonte, MG, Brazil and I'm lazy now, read this list
> and search the web for "tapestry 6" to know what I'm talking about . . . ;)
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: generics and pages, components and edit blocks

[Luther Baker]

Yes.

Maybe Tapestry 6 :)

Given that the language keeps changing/moving forward, this seems like an
odd thing to simply leave the user with ... I would guess that Templates,
Components, Pages ... and the way we setup Services in AppModule would
eventually want to consider techniques that wish to leverage Generics.
Obviously, registering something like DataService.class is illegal
Java - so it may take a creative approach.

Obviously from a page/component standpoing, there'd have to be a new
convention for such beasts. Naively:

note/EditBlock_Note
idea/EditBlock_Idea

And Services (interfaces and implementations) would be a completely
different problem ... and with things like type erasure and backwards
compatibility ... it all strikes me as an interesting issue.

-Luther



On Sun, Mar 8, 2009 at 6:55 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Sun, 08 Mar 2009 15:46:19 -0300, Luther Baker 
> escreveu:
>
>  Is there anyway to use generics as pages, components or edit blocks?
>>
>
> No, because Tapestry uses the class name as URL.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

generics and pages, components and edit blocks

[Luther Baker]

Is there anyway to use generics as pages, components or edit blocks?


path/Edit

vs

path/Edit


I'd imagine not - you'd have had to encoded the Generic type in the class
and page names somehow and I've not seen anyone do that yet.

-Luther

Re: Tabindex and accesskey in BeanEditForm?

[Luther Baker]

Take a look at Thiago's response to my *similar* question earlier today:

http://www.nabble.com/t%3ATextField-and-t%3ATextArea-to22375618.html

-Luther


On Fri, Mar 6, 2009 at 3:25 PM, leechj  wrote:

>
> Hello,
> I was wondering if there was an easy way to add properties to fields in a
> BeanEditForm.
> Our application needs "tabindex" and "accesskey" in all fields in order to
> comply with federal rules dealing with accessibility. Is there a way to add
> these 2 properties to the fields in the form or should I just create the
> form by hand instead of using BeanEditForm?
>
> Thanks for any help!
>
>
> --
> View this message in context:
> http://www.nabble.com/Tabindex-and-accesskey-in-BeanEditForm--tp22380749p22380749.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
>
>

t:TextField and t:TextArea

[Luther Baker]

Is there a global way to explicitly set or override *html *(non-CSS)
attributes on tapestry components like textfield and textarea?

For instance, in one particular app, I have to override almost all of my
components with t:Parameters that define slightly custom sizes for these:

textfield: size="106" maxlength="105"
textarea: cols="80" rows="4"

But in my case, these custom sizes apply to 90% of the fields in the 15
forms.

-Luther

Date Validation

[Luther Baker]

I have a Hibernate entity - which contains a java.util.Date.

It displays just fine in a BeanEditor ... if I intentionally enter a
mis-formatted date it correctly comes back highlighted in a RED outline etc.

Then, *when I try to click on the CALENDAR icon *- it just keeps telling me
the date is incorrectly formatted. IE: a graphic block fades in above the
field with an arrow and a red X telling me about the problem - but the
CALENDAR never pops back up to let me select.

I have to manually swipe and delete the entry in the textbox - and then
clicking on the CALENDAR icon works again.

Is that intentional? I mean, it works - but I don't think it is intuitive to
have to delete the entry before clicking on the CALENDAR icon.

-Luther

Re: Page navigation passed value not displayed (@InjectPage style)

[Luther Baker]

Try adding @Persist to the destination class ... otherwise, I'm not sure
you're guaranteed which page instance will get rendered.

public class SendingActivationEmail
{

  @Persist
  private String email;


-Luther


On Thu, Mar 5, 2009 at 7:10 PM, manuel aldana  wrote:

> Hi,
>
> I want to pass one value to one page with the InjectPage pattern (
> http://tapestry.apache.org/tapestry5/guide/pagenav.html). But below code
> does not work (email does not get displayed on other page).
>
>
> public class Registration
> {
>   @Property
>   private String email;
> @InjectPage
>   private SendingActivationEmail sendingActivationEmail;
>
>   @OnEvent(value = "submit", component = "newUser")
>   Object newUser()
>   {
>  //WHEN DEBUGGING VALUE GETS PASSED CORRECTLY
>   sendingActivationEmail.setEmail(email);
>   return sendingActivationEmail;
>   }
> }
> ---
> public class SendingActivationEmail
> {
>
>   private String email;
>
>   public String getEmail()
>   {
>   return email;
>   }
>
>   public void setEmail(String email)
>   {
>   this.email = email;
>   }
> }
> ---
> SendingActivationMail.tml (I would not see email printed here):
> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
>  We send an email to your registrated email ${email}. check it out.
> 
> 
>
> --
> manuel aldana
> ald...@gmx.de
> software-engineering blog: http://www.aldana-online.de
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: @Inject'ing Generic Services

[Luther Baker]

Explicit discussion about generics and ioc eludes me on that page - but I'll
keep looking around.

Thanks.

-Luther



On Wed, Mar 4, 2009 at 7:01 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Wed, 04 Mar 2009 21:47:31 -0300, Luther Baker 
> escreveu:
>
>  Can I safely @Inject this encoder into multiple/different pages?
>> class MoviePage
>> {
>>@Inject
>>private ValueEncoder encoder;
>>
>
> Java does not let you do that because of the way it implemented generics.
> Anyway, Select (and maybe some other components) use ValueEncoderSource to
> get a ValueEncoder for a given type. Take a look at
> TapestryModule.contributeValueEncoderSource().
>
>  If this is safe, although I only bound one instance, does it create a new
>> instance of the service for each Generic type?
>>
>
> It wouldn't work like you want.
>
>  What should happen with something like this:
>>binder.bind(AbstractSelectModel.class, GenericSelectModel.class);
>> when there is no "left-hand" Generic to infer the Generic Parameter from:
>> class VideoPage
>> {
>>@Inject
>>private AbstractSelectModel model;
>>
>
> I guess this would work. But I suggest you to use
> binder.bind(GenericSelectModel.class) (without the "left-hand") and then
> @Inject it like any other service.
>
> This is a purely Tapestry-IoC thing, not exactly a Tapestry-Core (web
> framework) issue. You can read more about injection and services at
> http://tapestry.apache.org/tapestry5/tapestry-ioc/service.html. I'm just
> parroting what's written there. :)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

@Inject'ing Generic Services

[Luther Baker]

The following is illegal Java ... so I cannot bind the following in my
AppModule:

binder.bind(ValueEncoder.class,
GenericValueEncoder.class);
binder.bind(ValueEncoder.class,
GenericValueEncoder.class);
binder.bind(ValueEncoder.class,
GenericValueEncoder.class);
binder.bind(ValueEncoder.class,
GenericValueEncoder.class);

Instead, I put the following into my AppModule:

binder.bind(ValueEncoder.class, GenericValueEncoder.class);

Can I safely @Inject this encoder into multiple/different pages?

class MoviePage
{
@Inject
private ValueEncoder encoder;


class VideoPage
{
@Inject
private ValueEncoder encoder;


If this is safe, although I only bound one instance, does it create a new
instance of the service for each Generic type?



What should happen with something like this:

binder.bind(AbstractSelectModel.class, GenericSelectModel.class);


when there is no "left-hand" Generic to infer the Generic Parameter from:

class VideoPage
{
@Inject
private AbstractSelectModel model;



-Luther

Re: PAGE Lifecycle vs COMPONENT render cycle

[Luther Baker]

> By the way, you can use Hibernate cache features to deal with that instead
of implementing it yourself.

Ahh ... I knew this ... but it is something I need to read up on.


> Again: each ValueEncoder method is invoked in different requests and it's
not a good idea to put object lists in memory (session).

Ok - I saw them both (model and encoder) retrieved at page load but I missed
its invocation on submit. This approach makes sense to me then.


> You're doing (bad, IMHO) premature optimization, and it is the root of all
evil. (I just love this quote :)).

Ohhh . well thanks for the warning! There are some obvious baddies I try
to avoid right away and this looked like double work - but I need to get my
head around hibernate caching a bit more.


> The framework does not tell you what to do: it just encourages you to
follow some proven paths, but you can choose to not follow them.

Thanks for helping illuminate the path.


Thanks,

-Luther



On Wed, Mar 4, 2009 at 2:00 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Wed, 04 Mar 2009 16:50:21 -0300, Luther Baker 
> escreveu:
>
>  ... my encoder implements this method:
>>public T toValue(String clientValue)
>>
>> So in my case, the encoder needs data from the database. I've spent cpu
>> cycles in getModel() to pull a list of items. It seems like I should
>> leverage that list when I hydrate the object back from it's screen
>> representation to an actual object ... no?
>>
>
> No. toValue() is only invoked when the form is submitted. The list loading
> happens in another request. It is not a good idea to keep the list on memory
> bacause each user session would have an enormous size. By the way, you can
> use Hibernate cache features to deal with that instead of implementing it
> yourself.
>
>  I guess - I could inject a dao or connection to the database into the
>> ValueEncoder - but on first glance, that seems like overkill ...
>>
>
> It is not. Service injection is very cheap. And tapestry-hibernate already
> provides a ValueEncoder for each entity class.
>
>  I just need to get comfortable with it. Iv'e got the list right there. It
>> can't have changed eh?
>>
>
> You're doing (bad, IMHO) premature optimization, and it is the root of all
> evil. (I just love this quote :)).
>
>  To sum up, the main issue here is that the object I'm 'toValue'ing exists
>> in the dbase (and in the model). The Wiki example for GenericSelectModel
>> queries the database two times but I think it is redundant to do so.
>>
>
> Again: each ValueEncoder method is invoked in different requests and it's
> not a good idea to put object lists in memory (session).
>
>  But again, if thats what the framework wants me to do - I'll work with it.
>>
>
> The framework does not tell you what to do: it just encourages you to
> follow some proven paths, but you can choose to not follow them.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: PAGE Lifecycle vs COMPONENT render cycle

[Luther Baker]

Thiago,

You are like superman on this forum.

Thanks for spending so much time here ... I for one don't know what I'd do
without these discussions.

I know it is a tangent but I've posted to other groups like the Grails
nabble group and NEVER EVER get any responses. A framework is worthless to
me if I can't quickly get into a feedback loop of sorts when I run into
problem. Keeping this forum so active has a lot of intangible benefits for
Tapestry world domination and I just thought it'd be worth saying.

Keep up the good work and thanks again for all the time you spend here.

-Luther




On Wed, Mar 4, 2009 at 12:27 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Wed, 04 Mar 2009 13:52:22 -0300, Luther Baker 
> escreveu:
>
>  If Block Edit isn't a page and it isn't a component ... is there a
>> predictable way to initialize it each time it is requested?
>> In my case, I have a Hibernate entity ... with a reference @ManyToOne - to
>> another entity. It is this child entity that has an edit block associated
>> with it. When I go to EDIT the parent entity, I need to load all possible
>> children entities into a select drop down and pick from them.
>>
>
> Forget about events in this case.
> Do it the easy way: you have to pass a SelectModel to the Select component
> though the model parameter.
> Something like:
>
> 
>
> Just do your initialization inside the getEntityModel() method:
>
> SelectModel getEntityModel() {
>// fetch children entities
>// populate SelectModel
>return selectModel;
> }
>
>  Therefore, I need to refresh that edit block drop down each time it
>> displays. Since I registered this block with the App Module - I don't
>> explicitly reference it in the actual page displaying the BeanEditForm.
>> Does that make sense? The BeanEditForm is instantiating the edit block
>> behind the scenes.
>>
>
> You're right. You don't need to use a lifecycle event to refresh the Select
> component because the model is requested everytime it (Select) is rendered.
>
>  So, I separated them - so I literally have a getModel and a getEncoder.
>> Now, if I can't depend on events with this app block - I could put the query
>> in one of these two - and I can see one hit before the other - but is that
>> order guaranteed?
>>
>
> Your encoder shouldn't depend on a pre-fetched list. Just fetch the encoded
> object in your encoder.
>
>  On that note, pageAttached is currently firing in my EditBlock.java class.
>>
>
> It is expected. Your page is activated when BeanEditForm gets a component
> from it.
>
>  Were you implying (in an early post) that I should depend on that in all
>> cases?
>>
>
> I don't even know what you mean here, but the answer is no. :)
> That I'm just lucky here? I didn't quite understand this comment:
>
>  since literally, void pageAttached() is declared and implemented in the
>> BlockEdit.java - and not literally the page. "declared it inside a page"
>> confuses me.
>>
>
> BlockEdit is a page that is not used as a regular page. Regular pages are
> requested though HTTP. BlockEdit is used just to declare blocks.
>
> Again: stop understanding lifecycle events in BlockEdit for a while and try
> to learn them on regular pages and components.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: PAGE Lifecycle vs COMPONENT render cycle

[Luther Baker]

>
> Your encoder shouldn't depend on a pre-fetched list. Just fetch the encoded
> object in your encoder.


... my encoder implements this method:

public T toValue(String clientValue)

So in my case, the encoder needs data from the database. I've spent cpu
cycles in getModel() to pull a list of items. It seems like I should
leverage that list when I hydrate the object back from it's screen
representation to an actual object ... no?

I guess - I could inject a dao or connection to the database into the
ValueEncoder - but on first glance, that seems like overkill ... but - maybe
I just need to get comfortable with it. Iv'e got the list right there. It
can't have changed eh?

To sum up, the main issue here is that the object I'm 'toValue'ing exists in
the dbase (and in the model). The Wiki example for GenericSelectModel
queries the database two times but I think it is redundant to do so.

But again, if thats what the framework wants me to do - I'll work with it. I
just needed to explore every option here to make sure I wasn't missing some
BlockEdit event ... it seems natural when components and pages have events
eh? But as natrual as I might intuit it, I do realize from your conversation
that Blocks just aren't made or implemented that way.




>
>
>  On that note, pageAttached is currently firing in my EditBlock.java class.
>>
>
> It is expected. Your page is activated when BeanEditForm gets a component
> from it.
>


My confusion here stems from my understanding that the edit block is NOT a
page and you' ve mentioned a few times "Your page is activatated ... and the
event fires." I understand that event fires - but shouldn't it be handled by
the PAGE and not the Edit Block?

When a page includes a component - does the component suddenly handle that
page's events? Likewise, I'm confused how the edit block (which is not a
page or a component) is getting the pageAttached event. I understand it is a
page event - I just don't understand why the Edit Block is handling it. Does
it fire in the Page.java as well? Is there a diagram or somethign to see
this?



> BlockEdit is a page that is not used as a regular page. Regular pages are
> requested though HTTP. BlockEdit is used just to declare blocks.
>
> Again: stop understanding lifecycle events in BlockEdit for a while and try
> to learn them on regular pages and components.
>

Remember here, my goal right now is not to understand events per se but to
get my custom select drop down working ... and it is indeed getting "void
pageAttached" -- so that is why I must proceed down understanding lifecycle
events for BlockEdit.

Learning about events for pages and components is fine - but I need to know
exactly how that applies to my current issue with the Edit Block. That is
what I am practicing :)

Thanks again,

-Luther

Re: PAGE Lifecycle vs COMPONENT render cycle

[Luther Baker]

If Block Edit isn't a page and it isn't a component ... is there a
predictable way to initialize it each time it is requested?

In my case, I have a Hibernate entity ... with a reference @ManyToOne - to
another entity. It is this child entity that has an edit block associated
with it. When I go to EDIT the parent entity, I need to load all possible
children entities into a select drop down and pick from them.

Therefore, I need to refresh that edit block drop down each time it
displays. Since I registered this block with the App Module - I don't
explicitly reference it in the actual page displaying the BeanEditForm. Does
that make sense? The BeanEditForm is instantiating the edit block behind the
scenes.

So, in the Java class associated with my edit block, I provide the model, I
provide the encoder ... and I want to query for the latest list of enties.
The Wiki example implements by the encoder and the model in the
GenericSelectModel ... and then provides "values" as the model and encoder.
If "getValues" queries the database and provides both the model and the
encoder -- it gets invoked 2 times (the t:Select model and encoder
parameters).

So, I separated them - so I literally have a getModel and a getEncoder. Now,
if I can't depend on events with this app block - I could put the query in
one of these two - and I can see one hit before the other - but is that
order guaranteed? If so - maybe I could compensate by checking a flag in
either method and loading the list as necessary - but all that seems like a
hack.

It seems that my edit block needs a prepare event of some sort, and then the
getModel and getEncoder methods are not burdened with also deciding if the
data is present.

Whoa - hope that wasn't too hard to follow. Please remember, I'm learning
more about Tapestry all the time - so please erase all this and set me
straight with the 'right' way. I seem to be going down a rabbit hole here if
events don't apply to app blocks.

On that note, pageAttached is currently firing in my EditBlock.java class.
Were you implying (in an early post) that I should depend on that in all
cases? That I'm just lucky here? I didn't quite understand this comment:

> A block is not a page nor a component. @PageAttached just worked because
you declared it inside a page.

since literally, void pageAttached() is declared and implemented in the
BlockEdit.java - and not literally the page. "declared it inside a page"
confuses me.

Does that long explanation make sense? I really appreciate all of your time
and input. Sorry for the long, belabored windedness :)

Thanks,

-Luther





On Tue, Mar 3, 2009 at 10:42 PM, Luther Baker  wrote:

> > Writing blocks for BeanEditForm/BeanEditor is a very confusing place to
> learn about them. ;)
>
> Yes -- necessity *is* the mother of invention :)
>
> Thanks for the explanation regarding blocks - I'm off to try some
> experiments now.
>
> Thanks again T.
>
> -Luther
>
>
>
>
> On Tue, Mar 3, 2009 at 9:15 PM, Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> Em Wed, 04 Mar 2009 00:00:28 -0300, Luther Baker 
>> escreveu:
>>
>>  I took a look and found this page on COMPONENT rendering:
>>> http://tapestry.apache.org/tapestry5/guide/rendering.html and I tried
>>> the
>>> literal method
>>>void setupRender
>>>
>>
>> In which class have you declared this method? If it was the page where you
>> put your edit and view blocks (let's call it BlocksPage), it wouldn't work,
>> as BlocksPage is never rendered (never requested), just blocks and
>> components declared inside it are. BlocksPage just exists because all
>> Tapestry blocks needs to be declared inside some page.
>>
>>  Does an edit block act like a page and not a component?
>>>
>>
>> A block is not a page nor a component. @PageAttached just worked because
>> you declared it inside a page.
>>
>>  And, am I missing something or is a PAGE lifecycle signficantly different
>>> than a COMPONENT lifecycle?
>>>
>>
>> A page is a component. It has the component lifecycle plus some events of
>> its own.
>>
>>  I had read and made the assumptions that  PAGEs
>>> were actually COMPONENTs themselves and because they are special maybe I
>>> could see a PAGE having *additional* lifecycle methods -
>>>
>>
>> This is absolutely correct.
>>
>>  but I wasn't ready for none of the COMPONENT lifecycle methods to trip.
>>>
>>
>> Again: a page used just to provide blocks does not react to component
>> lifecycle events because it is not being rend

Re: PAGE Lifecycle vs COMPONENT render cycle

[Luther Baker]

> Writing blocks for BeanEditForm/BeanEditor is a very confusing place to
learn about them. ;)

Yes -- necessity *is* the mother of invention :)

Thanks for the explanation regarding blocks - I'm off to try some
experiments now.

Thanks again T.

-Luther



On Tue, Mar 3, 2009 at 9:15 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Wed, 04 Mar 2009 00:00:28 -0300, Luther Baker 
> escreveu:
>
>  I took a look and found this page on COMPONENT rendering:
>> http://tapestry.apache.org/tapestry5/guide/rendering.html and I tried the
>> literal method
>>void setupRender
>>
>
> In which class have you declared this method? If it was the page where you
> put your edit and view blocks (let's call it BlocksPage), it wouldn't work,
> as BlocksPage is never rendered (never requested), just blocks and
> components declared inside it are. BlocksPage just exists because all
> Tapestry blocks needs to be declared inside some page.
>
>  Does an edit block act like a page and not a component?
>>
>
> A block is not a page nor a component. @PageAttached just worked because
> you declared it inside a page.
>
>  And, am I missing something or is a PAGE lifecycle signficantly different
>> than a COMPONENT lifecycle?
>>
>
> A page is a component. It has the component lifecycle plus some events of
> its own.
>
>  I had read and made the assumptions that  PAGEs
>> were actually COMPONENTs themselves and because they are special maybe I
>> could see a PAGE having *additional* lifecycle methods -
>>
>
> This is absolutely correct.
>
>  but I wasn't ready for none of the COMPONENT lifecycle methods to trip.
>>
>
> Again: a page used just to provide blocks does not react to component
> lifecycle events because it is not being rendered (it was not requested),
> just one of its blocks.
>
> I strongly suggest you to learn about events in Tapestry using writing very
> normal page (one that really renders HTML) and writing a simple component.
> Writing blocks for BeanEditForm/BeanEditor is a very confusing place to
> learn about them. ;)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

PAGE Lifecycle vs COMPONENT render cycle

[Luther Baker]

I created an edit block - and wired up a GenericSelectModel. All is well and
fine.

I populate that select model with a query from the database - so now, I'd
like to move that query from getModel or getEncoder to a lifecycle method.

I took a look and found this page on COMPONENT rendering:
http://tapestry.apache.org/tapestry5/guide/rendering.html and I tried the
literal method

void setupRender

but it never gets invoked. I also tried @SetupRender but still, no
invocation when I visit the page.

I dug around a bit more and found the PAGE lifecycle docs:
http://tapestry.apache.org/tapestry5/guide/lifecycle. At the bottom of the
page appear three methods and I implemented

void pageAttached()

and it worked! So here are my questions.

Does an edit block act like a page and not a component?

And, am I missing something or is a PAGE lifecycle signficantly different
than a COMPONENT lifecycle? I had read and made the assumptions that PAGEs
were actually COMPONENTs themselves and because they are special maybe I
could see a PAGE having *additional* lifecycle methods - but I wasn't ready
for none of the COMPONENT lifecycle methods to trip.

Am I missing something or am I safe in saying that PAGEs generally have 3
lifecycle hooks and only well-defined COMPONENTS have the setupRender ...
etc *render* cycle events.

Thanks,

-Luther

Re: An edit block issue ...

[Luther Baker]

Ah ... that works (as expected).

Clarification for me - I know that Tapestry creates "pools" of my pages.
Conceptually, I've often wondered how it does that - ie: does it nullify all
the fields between requests?

Given this example, is it safe to say that it nullifies or invalidates any
field in the components, pages, or mixins package? ...

And more to my question - leaves any other declared and instantiated fields
alone?

For instance, if I instantiate and assign some utility class to a page.field
- is it predictably going to persist and even retain values that I might set
in it across requests?

Thanks Thiago,

-Luther





On Tue, Mar 3, 2009 at 8:15 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 03 Mar 2009 23:10:46 -0300, Luther Baker 
> escreveu:
>
>  Render queue error in BeforeRenderTemplate[initiative/BlockEdit:sid]:
>> Failure reading parameter 'model' of component initiative/BlockEdit:sid:
>> Component class
>> com.fuzzybearings.notebook.web.pages.initiative.InitiativeLabeler may not be
>> instantiated directly. You should use an @InjectPage or @InjectComponent
>> annotation instead.
>>
>
> Tapestry loads page, component and mixin classes using a special
> classloader that changes them on the fly. That's why you must never, never,
> ever put a class or interface that is not a component in the components,
> pages, or mixins package. That's also why you cannot instantiate a
> component, page or mixin in your package: you must let Tapestry to do that.
>
> The solution is to move the InitiativeLabeler to another package outside
> com.fuzzybearings.notebook.web.pages.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

An edit block issue ...

[Luther Baker]

I've implement GenericSelectBlock and have a corresponding edit block
defined.

I've implemented a method to get the model for the t:Select component in the
*.tml block:

public AbstractSelectModel getModel()
{
List list =
this.persistenceService.findAll(InitiativeConstants.DOMAIN_CLASS);
Collections.sort(list);

this.values = new InjectedGenericSelectModel(list,
Initiative.class, "name", "id", this.propertyAccess,);
return this.values;
}


What I don't understand is how that succeeds and this one fails:


public AbstractSelectModel getModel()
{
List list =
this.persistenceService.findAll(InitiativeConstants.DOMAIN_CLASS);
Collections.sort(list);

labeler = new InitiativeLabeler();
this.values = new GenericSelectModel(list,
Initiative.class, "name", "id", this.propertyAccess);
return this.values;
}


The only thing I did was create the labeler. I don't use it for anything. If
I go one step farther - I get the same problem.

labeler = new InitiativeLabeler();
this.values = new InjectedGenericSelectModel(list,
Initiative.class, "name", "id", this.propertyAccess, labeler);
return this.values;

or

InitiativeLabeler labeler = new InitiativeLabeler();
this.values = new InjectedGenericSelectModel(list,
Initiative.class, "name", "id", this.propertyAccess, labeler);
return this.values;


No matter what I try, the error on the page reads:


Render queue error in BeforeRenderTemplate[initiative/BlockEdit:sid]:
Failure reading parameter 'model' of component initiative/BlockEdit:sid:
Component class
com.fuzzybearings.notebook.web.pages.initiative.InitiativeLabeler may not be
instantiated directly. You should use an @InjectPage or @InjectComponent
annotation instead.


Now, InitiativeLabeler is not a component nor does it implement or extend
anything other than an interface I made up to simply write a special type of
label into the select.options piece of GenericSelectModel. I would like to
inject different labelers into the GenericSelectModel when I create it.

Is there a trick here? The original GenericSelectModel works just fine - but
the Instantiating the Labeler seems to break something.

Thoughts?

-Luther

Re: GenericSelectOption

[Luther Baker]

That indeed works out just as well for me.

Let me know if this is something I should open a JIRA ticket for - I've not
done that before and not sure of the process but wouldn't mind at all.

Thanks,

-Luther



On Tue, Mar 3, 2009 at 1:43 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 03 Mar 2009 14:58:05 -0300, Luther Baker 
> escreveu:
>
>  I have implemented this and which to display a special character in the
>> drop down. ∋
>>
>
> A better solution would be to give Select an already Unicode-encoded string
> intead of relying in HTML entities. Intead of something like String label =
> "∋", use label = "\u220B" (or whatever the hexadecimal code point for &ni
> is).
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: GenericSelectOption

[Luther Baker]

I would like to display it as an option LABEL.

To test this, from within my GenericSelectOption class - I've explicitly
made the label a list of special characters:

public List getOptions()
{
List optionModelList = new ArrayList();
for (Initiative obj : this.list)
{
optionModelList.add(new OptionModelImpl(*"  ∋ &
 "*, obj));
}
return optionModelList;
}


and for what its worth from tapestry's OptionModelImpl:

public class OptionModelImpl extends AbstractOptionModel
{
public OptionModelImpl(String label, Object value)
{
this.label = label;
this.value = value;
}


and in this case, I'm seeing

  ∋ &  

outputt'd to the page.

-Luther

...
}





On Tue, Mar 3, 2009 at 12:58 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 03 Mar 2009 14:58:05 -0300, Luther Baker 
> escreveu:
>
>  I have implemented this and which to display a special character in the
>> drop down. ∋ Only, whenever I return this via the 'toClient' method of
>> the ValueEncoder for this, the result ends up being &ni; which prints
>> miserably.
>> Is there a different way to feed the String value into Tapestry such that
>> it won't convert '&' to & -- or, is there a better way to push special
>> characters into the drop down options.
>>
>
> Do you want to output ∋ as an option value or as an option label?
> ValueEncoders are used to produce the value. OptionModer is the one which
> carries the labels.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

GenericSelectOption

[Luther Baker]

I have implemented this and which to display a special character in the drop
down.

∋

Only, whenever I return this via the 'toClient' method of the ValueEncoder
for this, the result ends up being ∋ which prints miserably.

Is there a different way to feed the String value into Tapestry such that it
won't convert '&' to & -- or, is there a better way to push special
characters into the drop down options.

-Luther

Re: Enumeration - blankOption=NEVER

[Luther Baker]

Yes, that did it!
Thanks Robert



On Fri, Feb 27, 2009 at 3:32 PM, Robert Zeigler  wrote:

> Yes: make the field required.
>
> Robert
>
>
> On Feb 26, 2009, at 2/268:07 AM , Luther Baker wrote:
>
>  In a BeanEditForm, when displaying an enum member of a Hibernate Entity
>> 
>> is there programmatic way to set blankOption="NEVER"?
>>
>> Or must I explicitly create a >
>> -Luther
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: App Block

[Luther Baker]

Thank you much.
-Luther


On Sat, Feb 28, 2009 at 10:43 AM, nillehammer
 wrote:

> Hi Luther,
> there is an annotation @DataType(""). It is used to annotate
> accessors in you Entity. With this you can shortcut the
> DataTypeAnalyzer.  names the block to render the Type.
> Greetings nillehammer
>
> Luther Baker schrieb:
> > Is there a way to 'choose' which render block to use for a particular
> > context?
> >
> > I have created a DISPLAY and an EDIT render block for a
> GenericSelectModel
> > based on a Hibernate table of values.
> >
> > In one context, a Hibernate entity holds a reference to this entity and
> > terms it "Parent".
> >
> > In another context, a Hibernate entity holds a reference to this entity
> and
> > terms it "File Cabinet."
> >
> > I register the type with the AppModule - but is it possible to let the
> > component choose which app block to display? Is there another way to use
> the
> > GenericSelectModel with multiple labels?
> >
> > Thanks,
> >
> > -Luther
> >
>
> --
> http://www.winfonet.eu
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

App Block

[Luther Baker]

Is there a way to 'choose' which render block to use for a particular
context?

I have created a DISPLAY and an EDIT render block for a GenericSelectModel
based on a Hibernate table of values.

In one context, a Hibernate entity holds a reference to this entity and
terms it "Parent".

In another context, a Hibernate entity holds a reference to this entity and
terms it "File Cabinet."

I register the type with the AppModule - but is it possible to let the
component choose which app block to display? Is there another way to use the
GenericSelectModel with multiple labels?

Thanks,

-Luther

Enumeration - blankOption=NEVER

[Luther Baker]

In a BeanEditForm, when displaying an enum member of a Hibernate Entity 
is there programmatic way to set blankOption="NEVER"?

Or must I explicitly create a 

Identifying

[Luther Baker]

If I am overriding several TextFields (longer size) - what for="???" do I
use in the label?

Do I need to add something extra to my Java class to accommodate this case?
Otherwise, I get a bunch of duplicate ids on the page: Multiple  or  tags.




Delete
|
Cancel

Url
Title
Comments

Tags




When I try the obvious  ...  like

Url


The page just dies a miserable death.

Render queue error in BeginRender[bookmark/Edit:label]: Failure reading
parameter 'for' of component bookmark/Edit:label: Component bookmark/Edit
does not contain an embedded component with id 'bookmark.url'. Available
components: Delete, bookmark, label, label_0, label_1, label_2, label_3,
layout, pagelink, pagelink_0, pagelink_1, textarea, textarea_0, textarea_1,
textfield, textfield_0.


How is one supposed to do this type of override?

Re: App Block

[Luther Baker]

After restarting Jetty ... this change appears to not work for me. Can
anyone see why it might not be passing SELECTED value back to the
BeanEditForm?

I have implemented GenericSelectModel for a type "Note" but in the interest
of space, I've not included it here. To that point, I have BOLDED a line
below in the setter for Note in EditNoteBlock.java. When it is present, the
"Note" properly gets passed back to the BeanEditForm. When it is missing,
the resulting entity has no Note reference. That tells me that
PropertyEditContext is getting injected from the environment AND it is
passing its value to the BeanEditForm ... but I'm not sure what to do so
that it automatically populates the 'note' instance variable. Would it be
related to a problem in my GenericSelectModel class? I pulled that down from
the wiki - but not sure which method in there would be responsible or play a
role in the AUTOMATIC setting of this value.

I was using @Property above the Note instance declaration but to make this
example more obvious, I include the getters and setters explicitly - and
again, it only works when I implement 'setNote' and manually assign with
context.setPropertyValue(...).

Thoughts?

-Luther



*EditNoteBlock.java*

@SuppressWarnings("unused")
public class EditNoteBlock
{
@Environmental
private PropertyEditContext context;

@Inject
private PropertyAccess propertyAccess;

@Inject
private PersistenceService persistenceService;

private Note note;

private GenericSelectModel notes;

public GenericSelectModel getNotes()
{
List list = persistenceService.findAll(Note.class);
notes = new GenericSelectModel(list, Note.class, "title",
"id", propertyAccess);
return this.notes;
}

/**
 * @return the note
 */
public Note getNote()
{
return note;
}

/**
 * @param note the note to set
 */
public void setNote(Note note)
{
*// context.setPropertyValue(note);*
this.note = note;
}
}


*EditNoteBlock.tml*

http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>

Parent




*CreateNote.java
*
public class CreateNote
{
@Inject
private PersistenceService persistenceService;

@Property
private Note note;

Object onSuccess()
{
Date now = new Date();
note.setCreatedOn(now);
note.setLastModifiedOn(now);
persistenceService.create(note);
return ListNotes.class;
}
}


*CreateNote.tml*

http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>

List Notes

Create Note






On Tue, Feb 24, 2009 at 10:05 AM, Luther Baker wrote:

> I removed my explicit assignment to PropertyEditContext and it continues to
> work as you suggest ... and using BeanEditor works fine in this case.
>
> Thanks for the suggestions,
>
> -Luther
>
>
>
>
> On Mon, Feb 23, 2009 at 8:51 PM, Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> On Sun, Feb 22, 2009 at 8:17 PM, Luther Baker 
>> wrote:
>> > I have written an application property block (per the BeanEditForm
>> tutorial)
>> > for a custom type. Is there a ideal event in the block component when I
>> can
>> > assign the property to the PropertyEditContext?
>>
>> You don't assign values to PropertyEditContext:
>> BeanEditorForm/BeanEditor does that for you automatically. Note that
>> the tutorial never assign values to it.
>>
>> > c) one final note - if I validate the custom property in this edit block
>> -
>> > how do I indicate the problem ... if I don't have a form object etc as
>> the
>> > Validation page suggests,
>>
>> Use BeanEditor instead. BeanEditForm is nothing more than a Form
>> component with an Errors and a BeanEditor component declared inside
>> it.
>>
>> --
>> Thiago
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>

Re: App Block

[Luther Baker]

I removed my explicit assignment to PropertyEditContext and it continues to
work as you suggest ... and using BeanEditor works fine in this case.

Thanks for the suggestions,

-Luther



On Mon, Feb 23, 2009 at 8:51 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> On Sun, Feb 22, 2009 at 8:17 PM, Luther Baker 
> wrote:
> > I have written an application property block (per the BeanEditForm
> tutorial)
> > for a custom type. Is there a ideal event in the block component when I
> can
> > assign the property to the PropertyEditContext?
>
> You don't assign values to PropertyEditContext:
> BeanEditorForm/BeanEditor does that for you automatically. Note that
> the tutorial never assign values to it.
>
> > c) one final note - if I validate the custom property in this edit block
> -
> > how do I indicate the problem ... if I don't have a form object etc as
> the
> > Validation page suggests,
>
> Use BeanEditor instead. BeanEditForm is nothing more than a Form
> component with an Errors and a BeanEditor component declared inside
> it.
>
> --
> Thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

t:beandisplay

[Luther Baker]

Using the t:beandisplay I noticed a subtle bug?

Normally, empty fields get a label on the left and a   on the right.
This keeps the spacing correct.

E.g., my Hibernate Entity has two java.util.Date classes, createdOn and
modifiedOn.

When I display the Entity via t:beandisplay, the outer brown background
doesn't extend down to cover the last two properties -- so I investigated
and it turns out that for the empty date values, the   is being left
out of the right hand  - which is throwing the entire display out of
alignment. Right hand values get shifted up (two rows in my case) and start
to line up with incorrect left hand labels.

About 
Authors 
Content 
*Created On
Modified On
*Parent[0] Unfiled
Tags 
TitleUnfiled

I think the java.util.Date fields should render  

Does that sound correct?

-Luther

App Block

[Luther Baker]

I have written an application property block (per the BeanEditForm tutorial)
for a custom type. Is there a ideal event in the block component when I can
assign the property to the PropertyEditContext?

For instance, I have written a GenericSelectModel and it shows up correctly
according to my custom edit block. But I'm not sure, in my corresponding
Java class:

a) when to assign the selected value to the
PropertyEditContext.setPropertyValue method. Is there an event I will see?
The enclosing BeanEditor gets onSuccess ... but I'm not sure what event this
custom, inner component sees ... It has to be after the user clicks SUBMIT
since the value needs to already be set.

b) how this selected value, once it is in the PropertyEditContext  how
it is made available to my onSuccess method in the encapsulating BeanEditor.
Does that make sense? Do I add a PropertyEditContext to both classes?

c) one final note - if I validate the custom property in this edit block -
how do I indicate the problem ... if I don't have a form object etc as the
Validation page suggests,
http://tapestry.apache.org/tapestry5/guide/validation.html.

Thanks for any assistance.

-Luther

@Validate a user defined property

[Luther Baker]

I have a hibernate entity with a @ManyToOne mapping to another entity.

public class Flight implements Serializable {

@ManyToOne
public Company getCompany() {
return company;
}
...
}

I successfully registered both a display and an edit block for this property
so it renders correctly in components like  t:Grid and t:BeanFormEditor.

Now, I'd like to add @Validate("required") to this entity - only it isn't
having any effect.

public class Flight implements Serializable {

@Validate("required")
@ManyToOne
public Company getCompany() {
return company;
}
...
}

If I add this annotation to other String properties in that Entity, the
validation takes effect.

public class Flight implements Serializable {

@Validate("required")
public int flightNumber() { return flighNumber; }

@ManyToOne
public Company getCompany() {
return company;
}
...
}

I can create a t:form and manually validate this 'onSuccess' (
http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Submit.html)
but I was wondering if this were possible to do with annotations (
http://tapestry.apache.org/tapestry5/tutorial1/forms.html)

Thanks,

-Luther

Re: Consistency Bug?? in BeanDisplay vs BeanEditForm

[Luther Baker]

No problem.

I appreciate the feedback.

Time permitting, I'm going to try my hand at it - especially if others would
find value in the effort.

-Luther



On Wed, Feb 18, 2009 at 1:33 PM, Howard Lewis Ship  wrote:

> I see where you are coming from, but to "fix" it would break its usage
> by others.  I would fix BeanDisplay by making it the Block's
> responsibility to render the "label" (not a  element) and the
> value, just as BeanEditor requires its blocks to do.
>
> Again, I don't see this happening; it will be necessary to devise a
> new component for this purpose and change how contributions are made
> to it.  I'm afraid we're kind of stuck with it.
>
> On Wed, Feb 18, 2009 at 8:58 AM, Luther Baker 
> wrote:
> > Ah ... so follow me here:
> >
> > A) For an Entity with simple String properties, etc, both the
> t:BeanEditForm
> > and the t:BeanDisplay render:
> >
> > * LABEL: {component-specific-value}
> > LABEL: {component-specific-value}
> > *
> > B) If I add a t:Parameter called *whazoo* to either BeanDisplay or
> > BeanEditForm I have explicitly given the LABEL and VALUE. Right?
> >
> > C) Example: adding an "edit" t:Parameter
> >
> > > context="topic.id">edit
> >
> > Can easily produce
> >
> > *Edit: edit*
> >
> > And it does just this with the BeanDisplay (although it uses the dd
> family
> > of tags).
> >
> >> no way for them to bind a Label component to a component you will
> provide
> >
> > I'm not sure why you think it would be hard to generate the label.
> >
> > Are you referring here to a different label than the one we explicitly
> > provide in the t:Parameter name? Also, maybe I misunderstand but in my
> > example, the component is at a higher level than the extra t:Parameter.
> > Maybe I could get more extensive but in my case, I am just throwing in
> > another 'pseudo' label/value combo here when I use t:Parameter - and I'm
> > providing both values explicitly.
> >
> > Given the t:Parameter above, BeanEditDisplay displays:
> >
> > *edit*
> >
> > What I'm suggesting is that it *could* display a label as well as it is
> > explicitly provided.
> >
> > To that point - both in or both out. I guess BeanEditForm and BeanDisplay
> > could consistently display one way or the other. I think you can say that
> > "technically" they don't do this. Technically, BeanDisplay uses the 
> > family of tags whereas BeanEditForm uses s and s so it seems
> to
> > me that they were NOT written at the same time or with each other in mind
> >  and I guess you *could* say the components are completely unrelated
> and
> > have no cause or bearing to look like one another.
> >
> > But they *do* look like each other ... and they *are* related.
> >
> > So it seems to me that we could step back and now, today, look at them as
> a
> > family of components - related but with a slightly different purposes.
> Its
> > perfect for a CRUDdy application. Show, Edit, List.
> >
> > Maybe this is too simplistic of an example but I'd suggest that
> usage/render
> > consistency of this family of controls would actually add some value to
> the
> > library.
> >
> > They seem like two sides of the same coin ...
> >
> > Maybe my example is too simplistic. Just my $0.02 (or 1c :)
> >
> > Hope you don't think I'm being argumentative. It is sometimes difficult
> to
> > succinctly make a point via emails. In this case, I'm basically asking
> that
> > either BeanEditForm generate a label (which it explicitly has in the
> > t:Parameter) like it does for the other innate properties:
> >
> >  id="edit:label">Edit
> >
> > or that BeanDisplay not display the LABEL.
> >
> > Edit
> >
> > Nothing too too complicated I hope - just consistency. Admittedly, I am
> > surprised that the underlying HTML is so different between these two. At
> any
> > rate, I think both can have or disregard that label from a t:Parameter.
> > Sorry for the length here. I hope my argument makes sense.
> >
> > Thanks,
> >
> > -Luther
> >
> >
> > On Wed, Feb 18, 2009 at 6:13 AM, Thiago H. de Paula Figueiredo <
> > thiag...@gmail.com> wrote:
> >
> >> I see no inconsistence here. BeanEditForm (and BeanEditor) have a very
> >> different meaning than Grid and BeanDisplay. One is for editing data,
> >> the other 

Re: Consistency Bug?? in BeanDisplay vs BeanEditForm

[Luther Baker]

Ok - one last convincing attempt :) and then I'll let it go.

Like many developers, my current situation is to work with a designer. Two
principles this designer adheres to include - 1) collocate the links or
actions on the screen for the user and 2) try to generate some rhythm, if
possible, by placing actions or links in a consistent place from page to
page (menus, etc).

1) refers to keeping related actions like SUBMIT, CANCEL, RESET, CLEAR,
EDIT, etc together and with the data as opposed to scattering them on the
screen before, after and outside of the data making it difficult for the
user to intuit their relationship to the data. This has to do with spatial
relationship gobbly-gook.

2) refers to from page to page, keep the menu on the top or the left. Keep
the Submit buttons on the lower left of the div, etc. Kind of like a page
rhythm. Soomething like how on a portal, each block or element has menus, Xs
etc in the same spot (a top bar for each block if you will).

In my case, I think I incorrectly started using BeanEditForm for one of the
edit screens in this app and by default, it places the SUBMIT button in the
bottom left of the bright yellow box. To the design's first point, I needed
to put CANCEL, BACK and DELETE buttons on the page and he prefers that they
be near the SUBMIT button - so I used the t:Parameter for each of these and
it worked out as he needed.

Recently, I had to simply Display the contents of an entity and include an
explicit EDIT button. Since the users were already used to the BeanEditForm
and the lower left location of the SUBMIT button, that is where he requested
I put the EDIT button. So, I started with the t:BeanDisplay and used a
t:Parameter for the EDIT button.

Even though both Components display their native properties in 2 columns -
and both components put the textual label on the left and the component
specific value on the right - and both components draw big boxes around the
entire component using different background colors to differentiate them
(ie: they look very similar for the most part)  out of the box, they do
not render t:Parameter's consistently.

I guess I understand these particular components were not built to use this
way and that technically, you're suggesting it'd be difficlt to pull this
off. Either removing the LABEL that t:beandisplay forces or adding a LABEL
that t:beanedit (or t:beaneditform) leaves off (by LABEL, I don't mean html
- I mean key or title or whatever you call the left hand column of the
rendered display.

>> If you want edit and delete links in a BeanDisplay, put them after the
component, not inside. It is meant to only display an object.

Functionally, I think this works - but to use these components in a
commercially designed product ... I can't really tell the designer "put them
after the component, not inside" just because my framework makes that easy.

Ah well ... did that spiel convince you ;) how cool/reusable and applicable
such a change would be? It is probably a big mind shift from the original
point of those components - but I sorta thinks will become necessary. Up and
coming frameworks like Grails auto-generate Show, List and Edit screens for
the developer - and the edit.gsp and show.gsp screens are laid out very
similar. They generate action buttons and collocate them with the data you
are editing. (They generally do not auto-generate buttons in the upper right
corner of the header to edit data that is displayed in the middle of the
show.gsp screen.)

At any rate, I'm not suggesting we change anything - I think I'm making a
case to write my own first component(s)!

Good food for thought!

Thanks,

-Luther



On Wed, Feb 18, 2009 at 12:26 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Wed, 18 Feb 2009 13:58:46 -0300, Luther Baker 
> escreveu:
>
>  Ah ... so follow me here:
>>
>> A) For an Entity with simple String properties, etc, both the
>> t:BeanEditForm and the t:BeanDisplay render:
>>
>> * LABEL: {component-specific-value}
>> LABEL: {component-specific-value}
>>
>
> Take a look at the generated HTML. BeanEditor and BeanEditForm generate
> label tags through the Label component.
>
>  B) If I add a t:Parameter called *whazoo* to either BeanDisplay or
>> BeanEditForm I have explicitly given the LABEL and VALUE. Right?
>>
>
> BeanEditForm and BeanEditor, not BeanDispay.
>
>  And it does just this with the BeanDisplay (although it uses the dd family
>> of tags).
>>
>
> That's the difference.
>
>  I'm not sure why you think it would be hard to generate the label.
>>
>
> The Label component has a required parameter, for, that receives a
> component.
>
>  Are you referring here to a different label than the one we explicitly
>> provide in the t:Parameter name?
>>
>
>

Re: Consistency Bug?? in BeanDisplay vs BeanEditForm

[Luther Baker]

Ah ... so follow me here:

A) For an Entity with simple String properties, etc, both the t:BeanEditForm
and the t:BeanDisplay render:

* LABEL: {component-specific-value}
LABEL: {component-specific-value}
*
B) If I add a t:Parameter called *whazoo* to either BeanDisplay or
BeanEditForm I have explicitly given the LABEL and VALUE. Right?

C) Example: adding an "edit" t:Parameter

edit

Can easily produce

*Edit: edit*

And it does just this with the BeanDisplay (although it uses the dd family
of tags).

> no way for them to bind a Label component to a component you will provide

I'm not sure why you think it would be hard to generate the label.

Are you referring here to a different label than the one we explicitly
provide in the t:Parameter name? Also, maybe I misunderstand but in my
example, the component is at a higher level than the extra t:Parameter.
Maybe I could get more extensive but in my case, I am just throwing in
another 'pseudo' label/value combo here when I use t:Parameter - and I'm
providing both values explicitly.

Given the t:Parameter above, BeanEditDisplay displays:

*edit*

What I'm suggesting is that it *could* display a label as well as it is
explicitly provided.

To that point - both in or both out. I guess BeanEditForm and BeanDisplay
could consistently display one way or the other. I think you can say that
"technically" they don't do this. Technically, BeanDisplay uses the 
family of tags whereas BeanEditForm uses s and s so it seems to
me that they were NOT written at the same time or with each other in mind
 and I guess you *could* say the components are completely unrelated and
have no cause or bearing to look like one another.

But they *do* look like each other ... and they *are* related.

So it seems to me that we could step back and now, today, look at them as a
family of components - related but with a slightly different purposes. Its
perfect for a CRUDdy application. Show, Edit, List.

Maybe this is too simplistic of an example but I'd suggest that usage/render
consistency of this family of controls would actually add some value to the
library.

They seem like two sides of the same coin ...

Maybe my example is too simplistic. Just my $0.02 (or 1c :)

Hope you don't think I'm being argumentative. It is sometimes difficult to
succinctly make a point via emails. In this case, I'm basically asking that
either BeanEditForm generate a label (which it explicitly has in the
t:Parameter) like it does for the other innate properties:

Edit

or that BeanDisplay not display the LABEL.

Edit

Nothing too too complicated I hope - just consistency. Admittedly, I am
surprised that the underlying HTML is so different between these two. At any
rate, I think both can have or disregard that label from a t:Parameter.
Sorry for the length here. I hope my argument makes sense.

Thanks,

-Luther


On Wed, Feb 18, 2009 at 6:13 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> I see no inconsistence here. BeanEditForm (and BeanEditor) have a very
> different meaning than Grid and BeanDisplay. One is for editing data,
> the other for displaying data. BeanEditForm and BeanEditor replace the
> whole line because there's no way for them to bind a Label component
> to a component you will provide. If you want edit and delete links in
> a BeanDisplay, put them after the component, not inside. It is meant
> to only display an object. A workaround is to add the following lines
> to your app.properties.
>
> edit-label=
> delete-label=
>
> --
> Thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: rendering hibernate objects

[Luther Baker]

Whoa - stepping through a Tapestry request cycle, now that is alot of
dynamic code! It was a bit difficult to follow all that jit thread-specific
object creation ... especially since things were happening in placed I
didn't have breakcpoints ... but eventually, I think I got what I needed.

Basically, I built a translator for the t:TextField and added it to the
AppModule via contributeTranslatorSource.

Then, I changed the DISPLAY block Java code to use a Property*Output*Context
whilst the EDIT block code uses the Property*Edit*Context and whalah - it
seems to work.

I didn't have to mess with ValueEncoders or BeanModels at all - but I've not
implemented the SelectModel yet. That is tomorrow.

I do have one more question, my translator extends AbstractTranslator and
therefore must implement parseClient. My question is ... is it normal to
@Inject daos or hibernate services into something like a Translator? I'm not
sure how else to hydrate my Entity in the parseClient method ... but that
sounds like I'm adding alot of weight to that Translator. Is that normal? If
not, is there a better approach for that?

Thanks,

-Luther




On Tue, Feb 17, 2009 at 5:57 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 17 Feb 2009 20:25:49 -0300, Luther Baker 
> escreveu:
>
>  I had to strip a few parameters out and print literals for now. My next
>> question ... is how to get MY data into that class.
>>
>
> That's why @Environmental private PropertyEditContext context is there. ;)
> It is the bridge that takes you to the edited value.
>
> @Property
>>@Component(parameters =
>>{ "value=context.propertyValue" })
>>
>
>  Ah - (#1) I thought this was going to work - since only one or the other
>> block would be used at any given time. Since we are using the same java
>> class for either / or block ... it strikes me that I can't reuse t:id.
>>
>
> It doesn't matter if you use a component or not, they should have unique
> t:id's. If they're not unique, they aren't ids. ;) Don't forget that this is
> an ordinary page.
>
>  Does the corresponding Java class somehow discriminate and use my same
>> classification property object but with multiple ids? I think I'm
>> confusing
>> things - partly because I have little component writing experience.
>>
>
> When you inject a component in a page, you have to tell Tapestry what is
> its t:id. The name of the field is one way to do it. The other ones is
> @Component(id="someId").
>
>  but I'm not sure what to do to get that working. What is a 'translator'
>> and how do I write one ... and attach it to the context? And ... are those
>> appropriate questions?
>>
>
> Instead of trial and error, grap Tapestry's source code and read the
> PropertyEditBlocks class. It is where the Tapestry-provided blocks are
> declared. They should give you some hints. Use it as a starting point.
>
>  but that didn't turn out so well. "Could not convert '
>> context.propertyValue.name' into a component parameter binding
>>
>
> The return value of PropertyEditContext.getPropertyValue() is Object. By
> the way, it is exactly the property you're trying to edit, so there's no
> need to reference property names here.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Consistency Bug?? in BeanDisplay vs BeanEditForm

[Luther Baker]

In the BeanEditForm, every t:Parameter I provide replaces the entire row ...
there are not two columns. No key or label is present. Whatever I put in
t:Parameter takes up the entire row.

Whereas in BeanDisplay, every t:Parameter I provide gets forced into the
second column. No matter what I do, the label or name of that field always
get's printed on the left hand side.


edit



Delete


What that means to me is that when I jump back and forth between Edit and
Show screens in my crud(dy) application, the data lays out differently if I
use these two components.

I think they should render consistently ... but I'm not sure maybe they
really are unrelated and I need to write this myself.

For what its worth, the same thing happens when I provide any type of
AppPropertyBlock. If it is used on the BeanDisplay page, then the 'key' or
'label' automatically show up and the custom block is placed in the second
or right hand column. Again, for the BeanEditForm, no key or label shows up
and the block value simply takes the entire row.

Thoughts?

-Luther

Re: rendering hibernate objects

[Luther Baker]

>
> Ah - (#1) I thought this was going to work - since only one or the other
> block would be used at any given time. Since we are using the same java
> class for either / or block ... it strikes me that I can't reuse t:id.
>

> It doesn't matter if you use a component or not, they should have unique
t:id's. If they're not unique, they aren't ids. ;) Don't forget that this is
an ordinary page.


I'm with you here - what confused me is that in this case, my .tml file has
two blocks - of which only one will ever get used (depending on whether or
not we are editing). To mirror that, I guess the corresponding Java class
would likely have two properties, only one of which is used depending on the
behavior of that component.

Off to the source ...ahem, may the source be with you :)

Thanks.

-Luther




On Tue, Feb 17, 2009 at 5:57 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 17 Feb 2009 20:25:49 -0300, Luther Baker 
> escreveu:
>
>  I had to strip a few parameters out and print literals for now. My next
>> question ... is how to get MY data into that class.
>>
>
> That's why @Environmental private PropertyEditContext context is there. ;)
> It is the bridge that takes you to the edited value.
>
> @Property
>>@Component(parameters =
>>{ "value=context.propertyValue" })
>>
>
>  Ah - (#1) I thought this was going to work - since only one or the other
>> block would be used at any given time. Since we are using the same java
>> class for either / or block ... it strikes me that I can't reuse t:id.
>>
>
> It doesn't matter if you use a component or not, they should have unique
> t:id's. If they're not unique, they aren't ids. ;) Don't forget that this is
> an ordinary page.
>
>  Does the corresponding Java class somehow discriminate and use my same
>> classification property object but with multiple ids? I think I'm
>> confusing
>> things - partly because I have little component writing experience.
>>
>
> When you inject a component in a page, you have to tell Tapestry what is
> its t:id. The name of the field is one way to do it. The other ones is
> @Component(id="someId").
>
>  but I'm not sure what to do to get that working. What is a 'translator'
>> and how do I write one ... and attach it to the context? And ... are those
>> appropriate questions?
>>
>
> Instead of trial and error, grap Tapestry's source code and read the
> PropertyEditBlocks class. It is where the Tapestry-provided blocks are
> declared. They should give you some hints. Use it as a starting point.
>
>  but that didn't turn out so well. "Could not convert '
>> context.propertyValue.name' into a component parameter binding
>>
>
> The return value of PropertyEditContext.getPropertyValue() is Object. By
> the way, it is exactly the property you're trying to edit, so there's no
> need to reference property names here.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: rendering hibernate objects

[Luther Baker]

Got it! I can see my blocks rendering appropriately for both editable and
non-editable fields.

To come full circle, I need to better understand AppPropertyEditBlock.java.

I had to strip a few parameters out and print literals for now. My next
question ... is how to get MY data into that class.

public class AppPropertyEditBlocks
{
@Environmental
private PropertyEditContext context;

@Property
@Component(parameters =
{ "value=literal:cool class" })
private TextField classification;

public PropertyEditContext getContext()
{
return context;
}

public FieldValidator getClassificationValidator()
{
return context.getValidator(classification);
}

public FieldTranslator getClassificationTranslator()
{
return context.getTranslator(classification);
}
}


http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>

This came from AppPropertyEditBlocks.readableClassificationBlock ...



This came from AppPropertyEditBlocks.editableClassificationBlock ...




This works - but obviously puts "cool class" into the textfield.

Incremental changes:

http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>

This came from AppPropertyEditBlocks.readableClassificationBlock ...



This came from AppPropertyEditBlocks.editableClassificationBlock ...




Errors with: Component AppPropertyEditBlocks already contains a child
component with id 'classification'. Embedded component ids must be unique
(excluding case, which is ignored).

Ah - (#1) I thought this was going to work - since only one or the other
block would be used at any given time. Since we are using the same java
class for either / or block ... it strikes me that I can't reuse t:id. Does
the corresponding Java class somehow discriminate and use my same
classification property object but with multiple ids? I think I'm confusing
things - partly because I have little component writing experience.

(#2) mm ... how do I get ahold of my Classification value ;) I think it must
have something to do with the PropertyEditContext but changes like this

@Property
@Component(parameters =
{ "value=context.propertyValue",
"translate=prop:classificationTranslator" })
private TextField classification;

aren't quite enough. the DISPLAY block works just fine (no property is in
that block) but when using the BeanEditForm, I get an error: "Parameter
'translate' of component AppPropertyEditBlocks:classification is bound to
null. This parameter is not allowed to be null." I think that error must be
related to the method

public FieldTranslator getClassificationTranslator()
{
return context.getTranslator(classification);
}

but I'm not sure what to do to get that working. What is a 'translator' and
how do I write one ... and attach it to the context? And ... are those
appropriate questions?

As a side note, my guess is that PropertyEditContext magically encapsulates
the 'classification' object I am trying to render. I tried this

@Component(parameters =
{ "value=context.propertyValue.*name*",
"translate=prop:classificationTranslator" })

but that didn't turn out so well. "Could not convert '
context.propertyValue.name' into a component parameter binding: Class
java.lang.Object does not contain a property named 'name' (within property
expression 'context.propertyValue.name'). Available properties: class."

Thoughts? Maybe how does my "Classification" object get here ... and how do
I access it's properties ... and how do I attach translator ... or even a
validator if I've not defined one?

Thanks again,

-Luther



On Tue, Feb 17, 2009 at 3:47 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 17 Feb 2009 18:42:22 -0300, Luther Baker 
> escreveu:
>
>  You guys are great! Making more sense all the time...
>>
>
> You have just said nonsense! :p
>
>  Create and Edit (uses editable block) pages - Tapestry can't seem to find:
>> AppPropertyEditBlocks.tml
>>
>
> AppPropertyEditBlocks, or any other name you fancy, is an ordinary page
> (besides the fact that it won't be used to render HTML), so it must be its
> own class, located at the *pages* package. It's tml file should be at the
> same place you put your 'real' page templates.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: rendering hibernate objects

[Luther Baker]

ate
Topic

Edit Topic

Delete





5. Add another page with the t:BeanEditForm,
src/main/resources/${app.home}/pages/topic/EditTopic.java

http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>

List Topic

Create Topic





When I visit the CREATE or EDIT pages listed here - it gets closer but can't
seem to find: AppPropertyEditBlocks.tml

ERROR:

Render queue error in BeginRender[topic/Create:topic.editor.propertyeditor]:
Unable to locate a block to edit property 'classification' (with data type
'classification') of object { Topic { null }}: Unable to resolve
'AppPropertyEditBlocks' to a known page name

Right now - it is under the services directory (alongside AppModule and
AppPropertyEditBlocks.java) and I've confirmed that it is in the TARGET
directory.

I really think this is a trivial error ... but I've moved those two files
around to the pages dir, the components dir and the services dir ... but
always the same error. Seems to me my blocks pages isn't getting picked up
... Thoughts?

-Luther


On Tue, Feb 17, 2009 at 3:24 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Tue, 17 Feb 2009 18:13:51 -0300, Luther Baker 
> escreveu:
>
>  It trickie since it seems that Tapestry could call toString() on anything
>> without requiring this registration step. In this simplistic case,
>> registration didn't really tell it anything. But - given this registration
>> step - a few things make sense like ... before doing this, listing the
>> column name in the reorder clause of a t:grid was throwing an exception.
>>
>
> This exception happened because BeanModelSource didn't create a in a
> BeanModel property for Topic's classification property because it didn't
> know the Tapestry type for the Classification class. It's a very different
> issue.
>
>  :) One day - I hope to contribute BACK to Tapestry and than ... will have
>> arrived.
>>
>
> Everybody needs help and everybody can help. :)
> I didn't know that just providing a Tapestry type for a class would make
> BeanModelSource handle it. I learned something today. :)
>
>  Thanks for your timely input. One last post on the way.
>>
>
> You're welcome! :)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: rendering hibernate objects

[Luther Baker]

@Uli

false - that makes sense. I will apply it in my next post which actually
uses this method.


@Thiago

>> I'm not sure why assigning the name "classification" Classification
suddenly makes this work ...

> I guess it works because someone told Tapestry that it is a known type.

Yes - but doesn't every Java type have a toString method? And the trivial
registration did nothing (on appearance) but associate a key with a class.
It trickie since it seems that Tapestry could call toString() on anything
without requiring this registration step. In this simplistic case,
registration didn't really tell it anything. But - given this registration
step - a few things make sense like ... before doing this, listing the
column name in the reorder clause of a t:grid was throwing an exception. So
I gotcha, registration is required to tell Tapestry about this object -
plain and simple. Then, tweak as you like by using the blocks.

>> From now on, all your questions have already been answered. ;)

:) One day - I hope to contribute BACK to Tapestry and than ... will have
arrived.


Thanks for your timely input. One last post on the way.

-Luther



On Tue, Feb 17, 2009 at 2:04 PM, Ulrich Stärk  wrote:

> If you want to specify a block for displaying your type, you just do the
> same as with the editor but instead you contribute it with
>
> public static void
> contributeBeanBlockSource(Configuration
> configuration)
> {
>configuration.add(new BeanBlockContribution("school",
> "AppPropertyEditBlocks", "schoolViewBlock",
>    false));
> }
>
> (notice the false parameter now)
>
> Cheers,
>
> Uli
>
> Luther Baker schrieb:
>
>  Thanks both of you for your explanations - if you've got a bit of patience
>> with me, I need to walk through my thoughts to better understand the big
>> picture here. Thanks in advance for your points and help - they are very
>> helpful.
>>
>>
>> Ok, to set the stage in a little more detail: consider a basic GRAILS or
>> CRUD style app where my views are List.tml, Edit.tml and Show.tml.
>>
>>
>> I've broken this up into a few posts - in this response, *I'll focus on
>> List.tml, t:Grid and t:BeanDisplay* -- afterwhich, I'll try to segway into
>> a
>> post that leverages this information to discuss t:BeanEditForm.
>>
>> In this example, I'm using Topics and Classifications. Both are simple
>> entities - a Topic has a @ManyToOne relationship to Classifications. Each
>> Topic contains exactly one Classification. Many Topics can refer to the
>> same
>> Classification but again, any single Topic has exactly one Classification.
>>
>>
>> @Entity
>> public class Classification
>> {
>>@Id
>>@GeneratedValue(strategy = GenerationType.TABLE)
>>private Integer id;
>>
>>private String name;
>> ...
>> }
>>
>>
>> @Entity
>> public class Topic
>> {
>>@Id
>>@GeneratedValue(strategy = GenerationType.TABLE)
>>private Integer id;
>>
>>@ManyToOne
>>private Classification classification;
>> ...
>> }
>>
>>
>> Now consider List.tml:
>>
>> If I use a t:Grid out of the box, I get a runtime complaint when I try to
>> display a Topic,
>>
>>"does not contain a property named 'classification'"
>>
>> I assume this is because 'Classification' is not on the list of simple
>> types
>> that Tapestry currently knows about. Strings, booleans, numbers, etc. So,
>> I
>> add a defaultDataTypeAnalyzer:
>>
>>public static void
>> contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
>> configuration)
>>{
>>configuration.add(Classification.class, "classification");
>>}
>>
>> I'm not sure why assigning the name "classification" Classification
>> suddenly
>> makes this work ... but as soon as I do this, the t:Grid successfully
>> displays a Classification column - and populates it by invoking
>> Classification.toString(). Is that behavior overridable? Is it safe to say
>> I
>> don't need any other moving parts for this to work this way going forward?
>>
>> My next post will talk about BeanEditForm which I understand uses a
>> BeanModel, PropertyEditor, blocks etc - but as far as t:Grid is concerned
>> -
>> is there a special way to explicitly control how Classification DISPLAY's
>> itself (right now it invokes Classification.toString()) ? (ie: is there a
>> gro

Re: rendering hibernate objects

[Luther Baker]

If I am happy with using an Entities toString() method ... is this safe to
say:


For DISPLAYing an Entity via its "toString" method in something like t:Grid
or t:BeanDisplay

(1) add a line to AppModule.contributeDefaultDataTypeAnalyzer and
(2) implement toString() on the entity.

/**
 * Add a PropertyEditor for the Classification data type.
 *
 * @param configuration
 */
public static void
contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
configuration)
{
configuration.add(Classification.class, "classification");
}

@Entity
public class Classification implements Serializable, Identifiable,
Comparable
{
   

private String name;

   ...

   @Override
public String toString()
{
return this.name;
}
}


-Luther




On Tue, Feb 17, 2009 at 1:48 PM, Luther Baker  wrote:

> Thanks both of you for your explanations - if you've got a bit of patience
> with me, I need to walk through my thoughts to better understand the big
> picture here. Thanks in advance for your points and help - they are very
> helpful.
>
>
> Ok, to set the stage in a little more detail: consider a basic GRAILS or
> CRUD style app where my views are List.tml, Edit.tml and Show.tml.
>
>
> I've broken this up into a few posts - in this response, *I'll focus on
> List.tml, t:Grid and t:BeanDisplay* -- afterwhich, I'll try to segway into
> a post that leverages this information to discuss t:BeanEditForm.
>
> In this example, I'm using Topics and Classifications. Both are simple
> entities - a Topic has a @ManyToOne relationship to Classifications. Each
> Topic contains exactly one Classification. Many Topics can refer to the same
> Classification but again, any single Topic has exactly one Classification.
>
>
> @Entity
> public class Classification
> {
> @Id
> @GeneratedValue(strategy = GenerationType.TABLE)
> private Integer id;
>
> private String name;
> ...
> }
>
>
> @Entity
> public class Topic
> {
> @Id
> @GeneratedValue(strategy = GenerationType.TABLE)
> private Integer id;
>
> @ManyToOne
> private Classification classification;
> ...
> }
>
>
> Now consider List.tml:
>
> If I use a t:Grid out of the box, I get a runtime complaint when I try to
> display a Topic,
>
> "does not contain a property named 'classification'"
>
> I assume this is because 'Classification' is not on the list of simple
> types that Tapestry currently knows about. Strings, booleans, numbers, etc.
> So, I add a defaultDataTypeAnalyzer:
>
> public static void
> contributeDefaultDataTypeAnalyzer(MappedConfiguration, String>
> configuration)
> {
> configuration.add(Classification.class, "classification");
> }
>
> I'm not sure why assigning the name "classification" Classification
> suddenly makes this work ... but as soon as I do this, the t:Grid
> successfully displays a Classification column - and populates it by invoking
> Classification.toString(). Is that behavior overridable? Is it safe to say I
> don't need any other moving parts for this to work this way going forward?
>
> My next post will talk about BeanEditForm which I understand uses a
> BeanModel, PropertyEditor, blocks etc - but as far as t:Grid is concerned -
> is there a special way to explicitly control how Classification DISPLAY's
> itself (right now it invokes Classification.toString()) ? (ie: is there a
> group of classes that work together similar to t:BeanEditForm?)
>
> In the t:BeanEditForm - one creates xhtml blocks - but it doesn't appear
> necessary for t:Grid. Is that because t:Grid is only DISPLAYing the
> property?
>
> When I use t:BeanDisplay, the same thing happens, Classification.toString()
> is invoked. That all sounds good and reasonable - I am just curious how, in
> a DISPLAY scenario, if there is a programmatic way to override the behavior?
>
> And, as a side note, looking for a brief explanation as to why
> 'contributeDefaultDataTypeAnalyzer' makes this work.
>
> End of Part 1 :) DISPLAYing hibernate entities: t:Grid and t:BeanDisplay
> ... is it simpler than t:BeanEditForm? and can I override the toString
> invocation and why does contributeDefaultDataTypeAnalyzer have to happen
> here?
>
> Always happy to look at docs for this if you have any links to show.
>
> Thanks very much - I'm off to try some of the notes for t:BeanEditForm and
> I'll get back to you.
>
> -Luther
>
>
>
>
> On Tue, Feb 17, 2009 at 5:34 AM, Ulrich Stärk  wrote:
>
>> Here is your overview (assuming that you want to render your 

Re: rendering hibernate objects

[Luther Baker]

> In your AppModule you have to make contributions to the
> DefaultDataTypeAnalyzer and the BeanBlockSource services.
>
> public static void contributeDefaultDataTypeAnalyzer(
>MappedConfiguration configuration)
> {
>configuration.add(School.class, "school");
> }
>
> This will assign the name school to your school type for use within
> tapestry.
>
> With
>
> public static void
> contributeBeanBlockSource(Configuration
> configuration)
> {
>    configuration.add(new BeanBlockContribution("school",
> "AppPropertyEditBlocks", "schoolBlock",
>true));
> }
>
> you tell Tapestry to render a property of type school with the block
> "schoolBlock" inside the AppPropertyEditBlocks page.
>
> HTH,
>
> Uli
>
> Luther Baker schrieb:
>
>  Given two hibernate objects and a many-to-one relationship
>>
>> school
>> {
>>  name
>> }
>>
>> student
>> {
>>  firstname
>>
>>  @ManyToOne
>>  school
>> }
>>
>>
>> I want to pass something like this into a BeanEditForm and have the it
>> invoke school.toString() or possibly, school.getName().
>>
>> I know I can add a t:Parameter to t:BeanEditForm but it seems that I
>> should
>> be able to somehow register the School type with Tapestry and have it
>> simply
>> invoke school.toString() when required to render itself.
>>
>> I've looked at
>> http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlockbut
>> found it a bit confusing. At some high level, is there a brief synopsis of
>> the different players required to do this?
>>
>> PropertyEditor
>> ValueEncoder
>> DataTypeAnalyzer
>> PropertyEditContext
>> @Environmental
>> the Model ... etc.
>>
>> Now, on the other hand, is the BeanEditForm really considered just a
>> starter
>> component and is generally not used for production code? In which case, is
>> it just fine to come up with custom solutions to determine types and how
>> to
>> render them? Or is there a strong reason to go through all of this ...
>> when
>> I want to render a nested Hibernate Entity with a toString().
>>
>> Thanks,
>>
>> -Luther
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

rendering hibernate objects

[Luther Baker]

Given two hibernate objects and a many-to-one relationship

school
{
  name
}

student
{
  firstname

  @ManyToOne
  school
}


I want to pass something like this into a BeanEditForm and have the it
invoke school.toString() or possibly, school.getName().

I know I can add a t:Parameter to t:BeanEditForm but it seems that I should
be able to somehow register the School type with Tapestry and have it simply
invoke school.toString() when required to render itself.

I've looked at
http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlock but
found it a bit confusing. At some high level, is there a brief synopsis of
the different players required to do this?

PropertyEditor
ValueEncoder
DataTypeAnalyzer
PropertyEditContext
@Environmental
the Model ... etc.

Now, on the other hand, is the BeanEditForm really considered just a starter
component and is generally not used for production code? In which case, is
it just fine to come up with custom solutions to determine types and how to
render them? Or is there a strong reason to go through all of this ... when
I want to render a nested Hibernate Entity with a toString().

Thanks,

-Luther

beandisplay vs beanformedit

[Luther Baker]

Why does the following create a LEFT HAND  cell that says "Edit:" and
puts this t:Parameter on the right hand side


edit



while this entry leaves the entire additional row blank - no label or
anything is displayed automatically.


Delete



Are they not both based on the same underlying HTML?

-Luther

powered by

[Luther Baker]

Googling 'powered by Tapestry logo' bring back posts with dead links.
Is there a current, official logo I can post on my pages for this?'

-Luther

Re: intellij

[Luther Baker]

A strange factoid ... the reason I am even trying this is that this app
stopped working for me (in Eclipse) yesterday afternoon and I wanted to
triangulate the problem so I fired up intelliJ. I even downloaded NetBeans
and initally, they all reported the same problem - missing TML files. I got
it working in IntelliJ by making the aforementioned changes here - but
builds in NetBeans and Eclipse continued to complain.

So I looked a little deeper. It turns out to be related to maven filters.
The day before, I googled and added 3 profiles to my pom file. Nothing
negative happened on that day but then yesterday, I had to run "mvn clean"
which explicitly cleared out the target directory.

Anyway, the application stopped working on the rebuild. It turns out that my
new profile and filter and filters were setup to filter out anything not
explicitly included in the  section. I wanted to apply a filter to
two files so I listed those two files explicitly in the  block ...
which doesn't quite work! Those files get copied but suddenly, nothing else
from src/main/resources did. After adding a second filter (set to false -
don't apply filtering) to copy all the rest of the resource files - the
application started working in NetBeans and Eclipse ... and from the command
line.

Point to take is that IntelliJ doesn't appear to adhere strictly to the pom
file when it build and deploys. With the directives suggested here - it was
copying all the *.tml files to the target directory in spite of the explicit
maven filter listing only two files. I mention this for your benefit or to
see if I've got it wrong with the group that'd most likely have been
affected by this behavior.

At any rate, this last post !?*.java makes alot of sense as far as a general
setting in IntelliJ. Adding it now. Thanks!

-Luther



On Sat, Feb 14, 2009 at 10:18 PM, Andreas Andreou  wrote:

> in compiler settings, set resource patterns to !?*.java (everything
> but java file)
>
> On Sun, Feb 15, 2009 at 3:22 AM, Angelo Chen 
> wrote:
> >
> > I think you have to update settings to include .tml file, can't remember
> that
> > where to update at this moment.
> >
> >
> > luther.baker wrote:
> >>
> >> I just downloaded IntelliJ 8.1 and imported my maven project.
> >>
> >> It correctly identifies src/main/resources as a src directory and copies
> >> the
> >> .properties files to target/classes ... but leaves the .tml files out.
> >>
> >> I will check my POM - maybe my filter is doing this ... but thoughts?
> >>
> >> Thanks,
> >>
> >> -Luther
> >>
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/intellij-tp22018739p22018968.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
> >
> >
>
>
>
> --
> Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr
> Tapestry / Tacos developer
> Open Source / JEE Consulting
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: intellij

[Luther Baker]

You were right - I dug a little deeper and found it had to be added in the
settings.

http://www.nabble.com/-T5--.tml-files-not-recognized-in-IntelliJ-td21616318.html

Thanks much.

-Luther



On Sat, Feb 14, 2009 at 7:22 PM, Angelo Chen wrote:

>
> I think you have to update settings to include .tml file, can't remember
> that
> where to update at this moment.
>
>
> luther.baker wrote:
> >
> > I just downloaded IntelliJ 8.1 and imported my maven project.
> >
> > It correctly identifies src/main/resources as a src directory and copies
> > the
> > .properties files to target/classes ... but leaves the .tml files out.
> >
> > I will check my POM - maybe my filter is doing this ... but thoughts?
> >
> > Thanks,
> >
> > -Luther
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/intellij-tp22018739p22018968.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
>
>

intellij

[Luther Baker]

I just downloaded IntelliJ 8.1 and imported my maven project.

It correctly identifies src/main/resources as a src directory and copies the
.properties files to target/classes ... but leaves the .tml files out.

I will check my POM - maybe my filter is doing this ... but thoughts?

Thanks,

-Luther

Login

[Luther Baker]

Is anyone aware of a code example integrating JSecurity with Tapestry5?

I'm not sure how to best translate the HttpServletRequest type examples on
the JSecurity site.

I'm a bit put off by the ACEGI stuff ... but honestly not looked into it. Is
there a Tapestry consensus to just use that approach?

-Luther

Re: [T5] Struggling With Concepts

[Luther Baker]

>From your perspective, how does 'site' differ from the application context?

-Luther



On Fri, Feb 13, 2009 at 8:16 PM, xfile80303  wrote:

>
> Hello all,
>
> I've been struggling to understand the concepts surrounding T5 and have
> reached a pinnacle of frustration while trying to implement a (supposedly)
> simple piece of functionality.  I could very much use some guidance.
>
> What I'm trying to do is have a piece of information specifiable on the URL
> which will persist throughout the experience of the user.
>
> Specifically, I am trying to create an application which will be "site
> aware" (where "site" is a made-up term which implies different
> configurations/access/etc.).  The "site" will need to be present in the URL
> in some form.  With URL re-writing I suppose it is possible to have this as
> a parameter on the URL, or some other way which can be re-written into a
> Tapestry compatible form, but even so, I'm not sure what approach that form
> should take.
>
> If it is a parameter on the URL, how will that parameter persist while the
> user is browsing through the app, submitting forms, clicking links, etc?
>
> If it is an activation context, how would /that/ persist?
>
> Ultimately the ideal solution would be to have this "site" specified early
> in the URL and have Tapestry keep it there (and allow me to access its
> value) throughout the use of the app by a client.
>
> Something like:
>
> http://mysite.com/foosite/blah/blah/blah
>
> where "foosite" would be any string.
>
> As mentioned above, I suppose this could be:
>
> http://mysite.com/blah/blah/blah?site=foosite
>
> or
>
> http://mysite.com/blah/blah/blah/foosite
>
> if that makes achieving this with Tapestry any easier.
>
> I feel that Tapestry has the potential to be very useful and a great
> platform to develop on, but I'm really struggling to understand how to do
> this.
>
> Many Thanks,
>
> Levi
> ---
> For reference, here is a my previous thread:
> http://n2.nabble.com/-T5--URL-Manipulation-tt2276010.html
> --
> View this message in context:
> http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2324920.html
> Sent from the Tapestry Users 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: Hibernate ID

[Luther Baker]

Thank you Thiago.

-Luther



On Mon, Feb 9, 2009 at 8:53 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:

> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker 
> escreveu:
>
>  This is a little offtopic - so I apologize in advance but I'm building
>> Tapestry applications and have a Hibernate question that I'd like to pose
>> here.
>> Is there preferred type for simple Hibernate IDs?
>>
>
> I always use an artificial (i.e. a column that is used only as id, not
> being used to store real data) integer column generated by the DBMS as a
> table primary key. I always use Integer, unless I expect the number of rows
> to be huge. In that cases, I use Long.
>
> By the way, *never* use compound primary keys or any natural id column.
> That's my advice. It's simple, it's fast, it prevents some very bad problems
> when you need to change the database structure.
>
>  Simply stated, I'm asking about the two orthogonal choices: (native vs
>> object, range or size)
>> Is an int preferred to an Integer? Is there a compelling argument for
>> either native or Object?
>>
>
> I guess that you mean "primite" when you mean "native".
> Native types in Java can't have null values, so, for primary key
> properties, a Integer is a much better fit than an int.
>
>  Is an Integer preferred to a Long (if the extra range of the the Long is
>> unecessary)?
>>
>
> Yes.
>
>  For instance, using hsqldb - would a Long possibly require TWO columns and
>> an Integer only one?
>>
>
> No. A Long would require a 64 bits column type in the DBMS.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Hibernate ID

[Luther Baker]

This is a little offtopic - so I apologize in advance but I'm building
Tapestry applications and have a Hibernate question that I'd like to pose
here.

Is there preferred type for simple Hibernate IDs?

Simply stated, I'm asking about the two orthogonal choices: (native vs
object, range or size)

Is an int preferred to an Integer? Is there a compelling argument for either
native or Object?

Is an Integer preferred to a Long (if the extra range of the the Long is
unecessary)? For instance, using hsqldb - would a Long possibly require TWO
columns and an Integer only one?

If anyone has time to chime in briefly, I'm just asking for the most
generally used/accepted practices.

-Luther

Re: t:Select

[Luther Baker]

Whoa nice. I missed the blankLabel parameter.

Gracias Thiago - thanks for being such an active member here.

-Luther



On Jan 19, 2009, at 7:41 PM, Thiago H. de Paula Figueiredo wrote:

Em Mon, 19 Jan 2009 21:23:45 -0300, luther.baker > escreveu:


Now concerning, the first or *blank*value - I'd like to replace it  
with some text like "... choose one".


Try the blankLabel parameter: http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Select.html 
.


So, if using , is there a way I can add  
an option ... and make sure it shows up at the top of the select  
element?


Or put enumValue-blanklabel in your app.properties.

To make sure it appers, set the parameter blankOption="always".

--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

-
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: Blog post about Tapestry 5 - Project Structure

[Luther Baker]

Nice.

On Mon, Dec 22, 2008 at 11:32 PM, Borut Bolčina wrote:

> I made another post at
> http://bbwebcraft.blogspot.com/
> Task 2 – Explore the Tapestry 5 project structure and learn where to put
> your stuff
>
> I hope you don't consider this email as spam.
>
> Cheers,
> Borut
>

Re: T5: Proper project layout?

[Luther Baker]

For what it is worth, the directory structure you are referring to is really
dictated by Maven and not Tapestry per-se.

Normally, Maven build commands do not copy non-Java files from
'src/main/java' into the resulting archive. Per Maven convention, non-Java
files that should end up in the classpath should be in 'src/main/resources'.

But for example, Eclipse was not built around nor does it have to adhere to
Maven standards. As far as Tapestry is concerned, as long as the end result
is the same (Java and *.tml files have to be collocated in the classpath or
tml files belong in the web root) everything will work just fine.
Consequently, out of error, convenience or blatant disregard :-) different
developers place these SRC files in different places and configure their IDE
to create a proper end result - but per Maven conventions, to include text
(or non-Java) files in a resulting archive classpath, they should be kept in
the 'src/main/resources' path.

There is one additional point here. As I've alluded to, Tapestry is built to
look in TWO places for *.tml files. a) the classpath and b) the web root.
Remember, this is the RESULTING location. If you are using a Maven build
process, these equate to a) 'src/main/resources' and b) 'src/main/webapp'.

Much of the conversation in recent posts was around the best place to place
the *.tml files - ie: in the classpath or in the web application root. To
clarify, the jumpstart example you mention below is actually using the
CLASSPATH option but it is doing so contrary to Maven conventions. Remember
Tapestry cares only about the RESULTING location ... you are actually asking
about the SRC location. So again, if you like the approach that the
jumpstart example uses, and you alter your Maven build to include text files
from the java directory, you are fine ...

Small project with no one else on it? Do what you like and just make sure
the final build is conistent with what Tapestry requires. Larger project,
developers added and removed, long running? You may want to adhere more
tightly to a stricter, conventional Maven structure (orthogonal to Tapestry)
and keep your *.tml files in the webapp root or the resources directory.

If you have an automated build engine ... or continuous integration and you
want to run something like 'mvn install' from the command line over your
code ... convention would dictate that your *.tml files exist either in
'src/main/resources' (claspath) or 'src/main/webapp' (web application root).
Putting text files in the 'src/main/java' directory is a
"play-at-your-own-risk" move - very doable - but not per Maven conventions
 That said, you can customize your Maven pom.xml file --- but again,
that is generally frowned upon - especially when it comes to redefining
directories and files kept in custom paths. It adds complexity - you just
have to decide if it works for your org.

Hope that helps - sorry for the long-windedness. I'm a big fan of Maven -
and convention over configuration ... but if you get confused separating
your *.tml files the corresponding *.java files - by all means - optimize
your workflow. Just be aware of the tradeoffs you are making with such
customizations. Remember to distinguish the SRC locations from the RESULTING
locations in the archive. Tapestry doesn't care about the SRC location. You
can put your *.tml files in /home/tmp if you like. It is the resulting
ARCHIVE or Eclipse IDE that has to include them in either a) the classpath
or b) the webroot.

-Luther


On Thu, Dec 18, 2008 at 9:34 AM, Jonathan O'Connor wrote:

> Jonathan,
> yes, I used to be a big fan of spindle when I worked in Tap3, many moons
> ago!
> I'll grab it now.
> Ciao,
> Jonathan
>
>
> On 18/12/2008 15:15, Jonathan Barker wrote:
>
>> The Loom plugin for Eclipse (see link on the T5 main page) makes that
>> jumping around painless.
>>
>>
>>
>>
>>> -Original Message-
>>> From: Jonathan O'Connor [mailto:ninki...@eircom.net]
>>> Sent: Thursday, December 18, 2008 08:16
>>> To: users@tapestry.apache.org
>>> Subject: T5: Proper project layout?
>>>
>>> Hi,
>>> I've just started working with Tapestry 5, and I have found 2 different
>>> project layouts. Howard (I presume) suggested the one found in the
>>> guide: http://tapestry.apache.org/tapestry5/guide/project-layout.html
>>> and Geoff Callender has a different one in his jumpstart project. The
>>> main difference is that Geoff keeps the tml files in the same directory
>>> as the java classes. I prefer this as I don't need to jump about in the
>>> directory structure finding the matching Java or tml file. However, the
>>> guide explicitly says:
>>> "Component templates will always be stored in the resources folder." Is
>>> this documentation up to date?
>>>
>>> Thanks,
>>> Jonathan O'Connor
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>

t:Grid

[Luther Baker]

I have an Entity with a OneToOne relationship with another Entity. I'd like
to render the entire Entity (and child Entity) as a row in a t:Grid.

Per the classes at the bottom of this post, by default, the t:Grid displays
fname and lname, I'd like it to display fname, lname, category.name.

I'd just like some guidance as far as best-practice approach. Should I

a) add a column to the t:Grid and manually/explicitly render the nested
value in a t:Parameter block?
b) learn more about how to render types in a BeanEditor (BeanModel,
ValueEncoder, PropertyEditor).

I ask this because I'm not sure if it is encouraged to write your own
ValueEncoder, PropertyEditor BeanModel for most non-trivial objects. If the
answer is (b), are there any examples suggestions for a link that have
proved helpful for anyone else? How, when rendering Entity1 below can I
associate the right set of classes with the rendering engine so that the
embedded Entity2 will simply render itself correctly inline?

Thanks in advance,

-Luther



public class Entity2
{
  private String name;
}

public class Entity1
{
  private String fname;
  private String lname;

   @OneToOne
  private Entity2 category;
}

Entities referencing domain style Entities

[Luther Baker]

I have an entity that contains another entity - but this time, the contained
entity table is quite finite - say, 10 rows.

public class Category
{
  private String name;
}

public class User
{
   private String firstName;
   private String lastName;
   private Category category;
}

and in this case, I'd like to render firstName, lastName and a DROP DOWN or
some type of picker from existing Categories.

Would I need to create my own t:form ... and possibly use a t:BeanEditor
with a custom drop down/picker -- or is this type of idiom encapsulated in a
Tapestry component already?

Thanks much,

-Luther

Rendering Nested Entities

[Luther Baker]

Is there a relatively clean way to use a BeanEditForm and get a nested
Entities properties to show up as inputs.

public class Address
{
private String street;
...
}

public class User
{
private String firstName;
private String lastName;
private Address address;
...
}

Where firstname, lastName, and street would all be text inputs?

Thanks,

-Luther

Re: passivate/activate

[Luther Baker]

Ah ... thanks James.

I didn't realize that rendering a page would invoke onPassivate for the
pages included via *link tags.

I need to look for and watch this happen ... thanks very much.

-Luther



On Tue, Dec 9, 2008 at 1:38 AM, James Hillyerd <[EMAIL PROTECTED]> wrote:

> (I'm still learning to anyone feel free to correct me!)
>
> Think of it this way: onPassivate() is used to generate links to your a
> page.  Anytime you to t:pagelink, t:actionlink, or t:form - they all create
> an instance of your page (even if you don't specify a context), then call
> onPassivate on it.   I *think* each link/form etc will create it's own
> instance of the page (actually more likely fetching it from the cache) and
> call onPassivate.  So you could see this many times for a single .tml
> render.
> onActivate() doesn't necessarily need to be called first.  You could
> @Inject
> a page, call a setter on it, and then return it from an event handler.  I
> think Tapestry would then call onPassivate and use that to generate the
> redirect URL for the browser.  Then when your browser requests that URL,
> Tapestry will call the pages onActivate method to attempt restore the state
> you wanted.
>
> Does that make sense?  I know the labeling seems backwards, that's what
> made
> it hard for me to grasp - seems weird to passivate something that was never
> activated!
>
> -james
>
> On Mon, Dec 8, 2008 at 7:19 PM, Luther Baker <[EMAIL PROTECTED]>
> wrote:
>
> > Question about the flow.
> >
> > I GET ViewProject.tml with an activation context of "1" which invokes:
> >ViewProject.onActivate(Integer projectId)
> >
> > I echo the projectId to the screen as a context for a CreateIssue
> pagelink.
> > I visit or GET CreateIssue.tml which invokes:
> >CreateIssue.onActivate(Integer projectId)
> >Createissue.onPassivate()
> >
> >
> > *Q1*: ?? Why does onPassivate get called here - but not when I visited
> > ViewProject ??
> >
> >
> > I complete two fields on the CreateIssue.tml form and submit the form to
> > CreateIssue.java which invokes
> >CreateIssue.onActivate(Integer projectId)
> >CreateIssue.onSuccess()
> >
> >
> > *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
> >
> >
> > I return CreateIssue.onSuccess returns "ViewProject.class" which invokes:
> >ViewProject.onPassivate()
> >ViewProject.onActivate(Integer projectId)
> >
> >
> > *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml --- and
> yet,
> > onPassivate is invoked first. obviously, ViewProject has NO IDEA what
> > projectId to return since, it was invoked without an ACTIVATION context.
> Is
> > that why onPassivate is called? to find an activation context? I know the
> > docs say that if no activation context is passed - Tapestry will ask the
> > page for one. Is this how? If so - one need be a bit careful about how
> > onPassivate is implemented?
> >
> > Is there an HttpSession free way to forward to have CreateIssue.onSuccess
> > >>
> > ViewProject.onActivate(Integer projectId) ?
> >
> > So - I'm not sure how I can forward to another page and pass an
> activation
> > context along with the forward ... Is there a way? After taking a look
> > here,
> > http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html, I
> > decided to try to @InjectPage so that
> >
> > CreateIssue.onSuccess()
> > {
> >   nextPage.setProject(project);
> >   return nextPage;
> > }
> >
> > and changed ViewProject.onPassivate() to return project.getId() ...
> which,
> > is naturally used by ViewProject.Activate(Integer projectId) which is
> > called
> > next.
> >
> > Does that seem like the right way to do this? I don't need to @Persist as
> > the example has done - since with this method, I can cause onPassivate to
> > return what onActivate needs ... and I really don't need to save this
> info
> > after the request is handled... But, is it safe to assume that the
> instance
> > of the page returned by CreateIssue will be the instance that handles the
> > request ... ie: do I have a pooling concern when I'm directly assigning
> > page
> > properties?
> >
> > Man ... this is cool.
> >
> > -Luther
> >
>
>
>
> --
> James A. Hillyerd <[EMAIL PROTECTED]>
>

Re: passivate/activate

[Luther Baker]

@Geoff

Thanks for the URLs!

In your first example, you are injecting _page2 into Forms1, setting the
_firstName and _lastName ... and then returning that page instance. Then, in
Forms2 you DEPEND on _firstName and _lastName already being set!

Then, it seems like Forms2.onPassivate will return these (just set) values
to be used as the activation context ...

Object[] onPassivate() {
return new String[] { _firstName, _lastName };
}

Doesn't this pattern contradict your statement:

> Regardng pooling, you should assume the page instance you set up is NOT
the same instance that will be rendered.


IE: you set the firstname and lastname of the injected page ... but then it
seems you are depending on rendering that very instance?

Does that make sense? Thanks for your time and example,

-Luther



public class Forms1 {

@Property
private String _firstName;

@Property
private String _lastName;

@Component(id = "names")
private Form _form;

@Component(id = "firstName")
private TextField _firstNameField;

@Component(id = "lastName")
private TextField _lastNameField;

@InjectPage
private Forms2 _page2;

void onValidateForm() {
if (_firstName == null || _firstName.trim().equals("")) {
_form.recordError(_firstNameField, "First Name is 
required.");
}
if (_lastName == null || _lastName.trim().equals("")) {
_form.recordError(_lastNameField, "Last Name is 
required.");
}
}

Object onSuccess() {
_page2.set(_firstName, _lastName);
return _page2;
}


}

public class Forms2 {

private String _firstName;

private String _lastName;

// set() is public so that other pages can use it to set up this page.

public void set(String firstName, String lastName) {
_firstName = firstName;
_lastName = lastName;
}

// onPassivate() is called by Tapestry to get the activation context
to put in the URL.

Object[] onPassivate() {
return new String[] { _firstName, _lastName };
}

// onActivate() is called by Tapestry to pass in the activation
context from the URL.

void onActivate(String firstName, String lastName) {
_firstName = firstName;
_lastName = lastName;
}

public String getName() {
return _firstName + " " + _lastName;
}
}



On Tue, Dec 9, 2008 at 7:44 AM, Eric Ma <[EMAIL PROTECTED]> wrote:

>
> Very useful info, if you change http://localhost:8080 to
> http://jumpstart.doublenegative.com.au:8080 :-)
>
> Thanks Geoff for the great service to the community.
>
> Eric
>
>
> Geoff Callender-2 wrote:
> >
> > Do these links help?
> >
> > http://localhost:8080/jumpstart/examples/input/forms1
> >
> http://localhost:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
> > http://localhost:8080/jumpstart/examples/navigation/whatiscalledandwhen
> >
> > Regardng pooling, you should assume the page instance you set up is
> > NOT the same instance that will be rendered.
> >
> > Geoff
> >
> > On 09/12/2008, at 2:19 PM, Luther Baker wrote:
> >
> >> Question about the flow.
> >>
> >> I GET ViewProject.tml with an activation context of "1" which invokes:
> >>ViewProject.onActivate(Integer projectId)
> >>
> >> I echo the projectId to the screen as a context for a CreateIssue
> >> pagelink.
> >> I visit or GET CreateIssue.tml which invokes:
> >>CreateIssue.onActivate(Integer projectId)
> >>Createissue.onPassivate()
> >>
> >>
> >> *Q1*: ?? Why does onPassivate get called here - but not when I visited
> >> ViewProject ??
> >>
> >>
> >> I complete two fields on the CreateIssue.tml form and submit the
> >> form to
> >> CreateIssue.java which invokes
> >>CreateIssue.onActivate(Integer projectId)
> >>CreateIssue.onSuccess()
> >>
> >>
> >> *Q2*: ?? Why isn't CreateIssue.onPassivate called ??
> >>
> >>
> >> I return CreateIssue.onSuccess returns "ViewProject.class" which
> >> invokes:
> >>ViewProject.onPassivate()
> >>ViewProject.onActivate(Integer projectId)
> >>
> >>
> >> *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml ---
> >> and yet,
>

passivate/activate

[Luther Baker]

Question about the flow.

I GET ViewProject.tml with an activation context of "1" which invokes:
ViewProject.onActivate(Integer projectId)

I echo the projectId to the screen as a context for a CreateIssue pagelink.
I visit or GET CreateIssue.tml which invokes:
CreateIssue.onActivate(Integer projectId)
Createissue.onPassivate()


*Q1*: ?? Why does onPassivate get called here - but not when I visited
ViewProject ??


I complete two fields on the CreateIssue.tml form and submit the form to
CreateIssue.java which invokes
CreateIssue.onActivate(Integer projectId)
CreateIssue.onSuccess()


*Q2*: ?? Why isn't CreateIssue.onPassivate called ??


I return CreateIssue.onSuccess returns "ViewProject.class" which invokes:
ViewProject.onPassivate()
ViewProject.onActivate(Integer projectId)


*Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml --- and yet,
onPassivate is invoked first. obviously, ViewProject has NO IDEA what
projectId to return since, it was invoked without an ACTIVATION context. Is
that why onPassivate is called? to find an activation context? I know the
docs say that if no activation context is passed - Tapestry will ask the
page for one. Is this how? If so - one need be a bit careful about how
onPassivate is implemented?

Is there an HttpSession free way to forward to have CreateIssue.onSuccess >>
ViewProject.onActivate(Integer projectId) ?

So - I'm not sure how I can forward to another page and pass an activation
context along with the forward ... Is there a way? After taking a look here,
http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html, I
decided to try to @InjectPage so that

CreateIssue.onSuccess()
{
   nextPage.setProject(project);
   return nextPage;
}

and changed ViewProject.onPassivate() to return project.getId() ... which,
is naturally used by ViewProject.Activate(Integer projectId) which is called
next.

Does that seem like the right way to do this? I don't need to @Persist as
the example has done - since with this method, I can cause onPassivate to
return what onActivate needs ... and I really don't need to save this info
after the request is handled... But, is it safe to assume that the instance
of the page returned by CreateIssue will be the instance that handles the
request ... ie: do I have a pooling concern when I'm directly assigning page
properties?

Man ... this is cool.

-Luther

typo

[Luther Baker]

Just a small type on the Component Events page.

I don't think the trailing ** is correct below ..

http://tapestry.apache.org/tapestry5/guide/event.html

 Choose a number from 1 to 10: 



${index}

Additional parameter for beaneditform

[Luther Baker]

Scenario: I am creating Projects and Issues under those projects and have a
question about passing the projectid around.

Project.tml
Create
New Issue

CreateIssue.tml






Q1: notice, I have to add the projectId parameter. Also, 'newIssue' does NOT
have a projectId field. Submitting this form takes me to onSuccess where I'd
like to to retrieve the Project, create the Issue, call
issue.setProject(project) and then save the issue. But how do I retrieve the
projectId field since it is not part of my Issue entity?

Q2: after saving the new Issue, I'd like to return to the project screen. To
do that, I'd like to forward to a page/handler by passing the 'projectId'
again. How do I do that from onSuccess? I return a class - but how do I
include a parameter?

I think I am missing something. onActivate works when I am rendering a page
- but I'm not sure what similar method gets called while Posting ... and
before onSuccess where I can pull off the projectId.

Furthermore, is there a lifecycle method I can implement that would attach
projectId to the request so that the following page can get it? Maybe during
onPassivate? Just not sure how to pass it.

Thanks for any suggestions,

-Luther

small typo

[Luther Baker]

Just a small typo at the bottom of the page: there is an opening square
brace but no ending brace.

http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/ActionLink.html


  [delete

Re: architectural question

[Luther Baker]

That works just fine when I @Inject a hibernate session directly into a DAO
and say, persist an object ... but there's a catch.

In my world - a DAO is a very low level, granular thing. I inject DAOs into
my PersistenceService which gets invoked from my Management layer and I want
the Transaction definitions at the *PersistenceService *layer - not the
individual DAO layer. If I need to atomically commit 5 saves - I need to
define a service layer method with @CommitAfter.

In the following code snippet, I have the @CommitAfter where I'd logically
like it ... unfortunately, nothing gets persisted when I put it there. I
know the path is correct (web IS submitting a valid project object since,
this works fine when @CommitAfter is on the DAO method and the AppModule
@Match tag changes accordingly.

Thoughts?


*Tapestry config:
*
public class *AppModule*
{
public static void bind(ServiceBinder binder)
{
binder.bind(ProjectManager.class, SimpleProjectManager.class);
binder.bind(WriteDao.class, HibernateWriteDao.class);
binder.bind(PersistenceService.class, PersistenceService.class);
}

@Match("*PersistenceService")
public static  T
decorateTransactionally(HibernateTransactionDecorator decorator,
Class serviceInterface,
T delegate,
String serviceId)
{
T obj = decorator.build(serviceInterface, delegate, serviceId);
return obj;
}
}

*from the web request:*

public class *CreateProject*
{
@Inject
private ProjectManager projectManager;

@Property
private Project newProject;

Object onSuccess()
{
projectManager.createProject(newProject);
return ListProjects.class;
}
}

*invoked from CreateProject.onSuccess*:

public class SimpleProjectManager implements ProjectManager
{
@Inject
private PersistenceService persistenceService;

public void createProject(Project project)
{
persistenceService.createProject(project);
}
}

*invoked from SimpleProjectManager:**

* public class PersistenceService
{
@Inject
private Session session;

@Inject
private WriteDao writeDao;

@CommitAfter
public void createProject(Project project)
{
// imagine other db saves here - and assume these must all
succeed... or all fail
writeDao.persist(session, project);
}

}

*and finally
*
public class HibernateWriteDao implements WriteDao
{
public void persist(Session session, Object obj)
{
session.persist(obj);
}
}



On Fri, Dec 5, 2008 at 6:04 PM, Luther Baker <[EMAIL PROTECTED]> wrote:

> Thanks - that worked just fine.
>
> -Luther
>
>
>
> On Fri, Dec 5, 2008 at 1:41 PM, James Hillyerd <[EMAIL PROTECTED]> wrote:
>
>> Look at the bottom of this page:
>>
>> http://tapestry.apache.org/tapestry5/tapestry-hibernate/userguide.html
>>
>> It explains how to get @CommitAfter working with DAOs.
>>
>> -james
>>
>> On Fri, Dec 5, 2008 at 10:20 AM, Luther Baker <[EMAIL PROTECTED]>
>> wrote:
>>
>> > If I inject a Hibernate session into my DAO and have my Tapestry
>> Controller
>> > invoke that, is there a Tapestry way that I can tell hibernate to start
>> and
>> > commit a transaction via annotations or configuration?
>> >
>> > IE:
>> >
>> >
>> http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/BeanEditForm.html
>> >
>> > public class CreateUser
>> > {
>> >@Inject
>> >private UserDAO userDAO;
>> >
>> > ...
>> >Object onSuccess()
>> >{
>> >userDAO.add(user);
>> >
>> >return UserAdmin.class;
>> >}
>> > }
>> >
>> > public class UserDAO
>> > {
>> >@Inject
>> >private Session session;
>> >
>> >void add(User user)
>> >{
>> >session.persist(user);
>> >}
>> > }
>> >
>> >
>> > I tried to use @CommitAfter in my DAO but that didn't work. I
>> essentially
>> > want to simulate:
>> >
>> >void add(User user)
>> >{
>> >session.beginTransaction();
>> >session.persist(user);
>> >sessino.getTransaction().commit();
>> >}
>> >
>> > but I don't want to explicitly code this in my DAO for fear that I may
>> have
>> > some instances where the the transactional boundaries must be larger.
>> >
>> > Maybe this isn't a Tapestry specific thing - but I'm not sure how to
>> inject
>> > the Hibernate Session into my DAO but have my Tapestry Controller define
>> > the
>> > transactional boundaries ... was hoping some Tapestry annotations might
>> > help
>> > me out.
>> >
>> > -Luther
>> >
>>
>>
>>
>> --
>> James A. Hillyerd <[EMAIL PROTECTED]>
>>
>
>

Re: architectural question

[Luther Baker]

Thanks - that worked just fine.

-Luther


On Fri, Dec 5, 2008 at 1:41 PM, James Hillyerd <[EMAIL PROTECTED]> wrote:

> Look at the bottom of this page:
>
> http://tapestry.apache.org/tapestry5/tapestry-hibernate/userguide.html
>
> It explains how to get @CommitAfter working with DAOs.
>
> -james
>
> On Fri, Dec 5, 2008 at 10:20 AM, Luther Baker <[EMAIL PROTECTED]>
> wrote:
>
> > If I inject a Hibernate session into my DAO and have my Tapestry
> Controller
> > invoke that, is there a Tapestry way that I can tell hibernate to start
> and
> > commit a transaction via annotations or configuration?
> >
> > IE:
> >
> >
> http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/BeanEditForm.html
> >
> > public class CreateUser
> > {
> >@Inject
> >private UserDAO userDAO;
> >
> > ...
> >Object onSuccess()
> >{
> >userDAO.add(user);
> >
> >return UserAdmin.class;
> >}
> > }
> >
> > public class UserDAO
> > {
> >@Inject
> >private Session session;
> >
> >void add(User user)
> >{
> >session.persist(user);
> >}
> > }
> >
> >
> > I tried to use @CommitAfter in my DAO but that didn't work. I essentially
> > want to simulate:
> >
> >void add(User user)
> >{
> >session.beginTransaction();
> >session.persist(user);
> >sessino.getTransaction().commit();
> >}
> >
> > but I don't want to explicitly code this in my DAO for fear that I may
> have
> > some instances where the the transactional boundaries must be larger.
> >
> > Maybe this isn't a Tapestry specific thing - but I'm not sure how to
> inject
> > the Hibernate Session into my DAO but have my Tapestry Controller define
> > the
> > transactional boundaries ... was hoping some Tapestry annotations might
> > help
> > me out.
> >
> > -Luther
> >
>
>
>
> --
> James A. Hillyerd <[EMAIL PROTECTED]>
>

Re: Advantages of various .tml storage locations?

[Luther Baker]

@Jonathan

That works for me. Maven clean and then install.

I'm using Eclipse with M2 and Jetty plugins ... and have components and
properties files that load correctly from the resources dirs --- so my src
dirs were setup correctly. For whatever reason, after a Maven clean and
install ... my pages are now visible from the resources dir.

I even dropped Home.tml back into my webapp dir and left the other pages in
the resources dirs and the app works just fine. I explicitly checked the
target WAR file and work directories and sure enough, only Home.tml exists
in the root directory ... so I think its working as expected.

Thanks,

-Luther



On Fri, Dec 5, 2008 at 11:53 AM, Christian Edward Gruber <
[EMAIL PROTECTED]> wrote:

> I believe you are correct.
>
> Christian.
>
>
> On 5-Dec-08, at 12:38 , Jonathan Barker wrote:
>
>
>> Correct me if I'm wrong: specifying the resources directory in this way
>> means that the original (default) src/main/resources will not be used, so
>> if
>> you want to mix-and-match resource locations then you need to also specify
>> src/main/resources.
>>
>> I wouldn't want someone tripping on that issue.
>>
>> Jonathan
>>
>>
>>  -Original Message-
>>> From: Andreas Andreou [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, December 05, 2008 11:06
>>> To: Tapestry users
>>> Subject: Re: Advantages of various .tml storage locations?
>>>
>>> http://tacos.sourceforge.net/tacos4.1/tacos-core/quick-
>>> start/resolvers.html
>>> implements that for T4.1
>>> but the maven instructions mentioned there are what you're after... it
>>> boils down to redefining the
>>> resources location like this:
>>>
>>>   
>>>   ...
>>>   
>>>   
>>>   src/main/java
>>>   
>>>   **/*.java
>>>   
>>>   
>>>   ...
>>>   
>>>   ...
>>>   
>>>
>>>
>>> On Fri, Dec 5, 2008 at 1:05 PM, Maximilian Weißböck
>>> <[EMAIL PROTECTED]> wrote:
>>>
 I would much prefer solution number 1. as it keeps things
 on the same place that belong together.

 Sadly maven build does not work with this solution.
 Is there any maven guru how knows how to "fix" this?

 Thanks, Max

  -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
>
 James
>>>
 Hillyerd
> Gesendet: Donnerstag, 4. Dezember 2008 23:06
> An: Tapestry users
> Betreff: Advantages of various .tml storage locations?
>
> What are the pros/cons of keeping page .tml in:
>
> 1. src/main/java
>
>  vs
>
> 2. src/main/resources
>
>  vs
>
> 3. src/main/webapp
>
> ?
>
>
> I see JumpStart uses #1, and the tutorial uses #3.  Seems like it would
> easier to use #1 or #2 so at least the components and pages .tml are in
> the
> same directory tree.
>
> Thanks.
>
> -james
>
> --
> James A. Hillyerd <[EMAIL PROTECTED]>
>

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



>>>
>>>
>>> --
>>> Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr
>>> Tapestry / Tacos developer
>>> Open Source / JEE Consulting
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

architectural question

[Luther Baker]

If I inject a Hibernate session into my DAO and have my Tapestry Controller
invoke that, is there a Tapestry way that I can tell hibernate to start and
commit a transaction via annotations or configuration?

IE:
http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/BeanEditForm.html

public class CreateUser
{
@Inject
private UserDAO userDAO;

...
Object onSuccess()
{
userDAO.add(user);

return UserAdmin.class;
}
}

public class UserDAO
{
@Inject
private Session session;

void add(User user)
{
session.persist(user);
}
}


I tried to use @CommitAfter in my DAO but that didn't work. I essentially
want to simulate:

void add(User user)
{
session.beginTransaction();
session.persist(user);
sessino.getTransaction().commit();
}

but I don't want to explicitly code this in my DAO for fear that I may have
some instances where the the transactional boundaries must be larger.

Maybe this isn't a Tapestry specific thing - but I'm not sure how to inject
the Hibernate Session into my DAO but have my Tapestry Controller define the
transactional boundaries ... was hoping some Tapestry annotations might help
me out.

-Luther

Re: AW: Advantages of various .tml storage locations?

[Luther Baker]

Assuming this:

src/main/java/*com/X/app*/pages/Home.java


This doesn't work for me:

src/main/resources/*com/X/app*/pages/Home.tml


Wherease, this works just fine:

src/main/webapp/Home.tml


Do I need to do something special to drop my pages in the resources dir or
does this just work and I am overlooking something.

Thanks,

-Luther



On Fri, Dec 5, 2008 at 10:05 AM, Christian Edward Gruber <
[EMAIL PROTECTED]> wrote:

> It's not a fix, it's a design.  Code goes in /src/main/java. Resources go
> in /src/main/resources.  It's part of having a place for everything, and
> everything in its place.
>
> You could hack it by a custom execution of the resources plugin pointing to
> your "alternative resources location" (ie, src/main/java) but this isn't
> something that needs a solution - it's how the tool works.
>
> Actually, i think you could set the resources location to src/main/java
> anyway... one sec...
>
> Yep.
>
> Use the ... section of the pom to
> point at resources in /src/main/java.  eg:
>
> 
>
>/
>true
>${basedir}/src/main/java
> **/*.tml 
>
> 
> This should pick up .tml files in /src/main/java.  Not maven best practice,
> but if it works for you, have fun.  I still expect it will only work for
> components, not pages.  Howard?  True?
>
> Christian.
>
>
> On 5-Dec-08, at 06:05 , Maximilian Weißböck wrote:
>
>  I would much prefer solution number 1. as it keeps things
>> on the same place that belong together.
>>
>> Sadly maven build does not work with this solution.
>> Is there any maven guru how knows how to "fix" this?
>>
>> Thanks, Max
>>
>>  -Ursprüngliche Nachricht-
>>> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von James
>>> Hillyerd
>>> Gesendet: Donnerstag, 4. Dezember 2008 23:06
>>> An: Tapestry users
>>> Betreff: Advantages of various .tml storage locations?
>>>
>>> What are the pros/cons of keeping page .tml in:
>>>
>>> 1. src/main/java
>>>
>>>  vs
>>>
>>> 2. src/main/resources
>>>
>>>  vs
>>>
>>> 3. src/main/webapp
>>>
>>> ?
>>>
>>>
>>> I see JumpStart uses #1, and the tutorial uses #3.  Seems like it would
>>> easier to use #1 or #2 so at least the components and pages .tml are in
>>> the
>>> same directory tree.
>>>
>>> Thanks.
>>>
>>> -james
>>>
>>> --
>>> James A. Hillyerd <[EMAIL PROTECTED]>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: modules

[Luther Baker]

Ah .. thanks Howard. I was looking at the IoC module pages and skipped the
front altogether.

One minor html note .. on the tapestry-core pages, the Tapestry Logo doesn't
lead back to the front page. For example, the logo on
http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/BeanEditForm.htmlleads
to
http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/which
is a raw Apache/2.2.10 directory listing.

Thanks,

-Luther


On Thu, Dec 4, 2008 at 8:40 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:

> It's not HiveMind, its Tapestry 5 IoC.
>
> Yes, there's explicit configuration.
> http://tapestry.apache.org/tapestry5/guide/conf.html
>
> On Thu, Dec 4, 2008 at 5:01 PM, Luther Baker <[EMAIL PROTECTED]>
> wrote:
> > I've create a simple Module class that has a static bind method. I've
> placed
> > the class in the *.services package.
> >
> > package my.app.services;
> >
> > public class MyAppModule
> > {
> >  public static void bind(ServiceBinder binder)
> >  {
> >  binder.bind(ProjectManager.class, SimpleProjectManager.class);
> >  }
> > }
> >
> > In a different Java class, I have
> >
> > @Inject
> >
> > private ProjectManager projectManager;
> >
> > But, when startup always complains ClassNotFound. Are there some explicit
> > IoC configuration (files, classnames, etc) directions? I'm not sure what
> > HiveMind is looking for ... Is it something anything in the 'services'
> > package? or something name based? Links?
> >
> > Thanks,
> >
> > -Luther
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

modules

[Luther Baker]

I've create a simple Module class that has a static bind method. I've placed
the class in the *.services package.

package my.app.services;

public class MyAppModule
{
  public static void bind(ServiceBinder binder)
  {
  binder.bind(ProjectManager.class, SimpleProjectManager.class);
  }
}

In a different Java class, I have

@Inject

private ProjectManager projectManager;

But, when startup always complains ClassNotFound. Are there some explicit
IoC configuration (files, classnames, etc) directions? I'm not sure what
HiveMind is looking for ... Is it something anything in the 'services'
package? or something name based? Links?

Thanks,

-Luther

Re: IE8 Compatibility Quick Fix

[Luther Baker]

I'm afraid this will be an unpopular suggestion - but does anyone else wish
there was a little simpler, manual/direct control over the  section of
the page?

Just my $0.02.

-Luther



On Wed, Oct 22, 2008 at 5:12 PM, samlai <[EMAIL PROTECTED]> wrote:

>
> Anybody knows how to do this?
>
> BTW, the css include tag right after head is the following:
>
> 
> type="text/css">
>
> Basically I want to be able to do the following:
>
> 
>
>  type="text/css">
> --
> View this message in context:
> http://www.nabble.com/IE8-Compatibility-Quick-Fix-tp19340728p20120755.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: css validation

[Luther Baker]

That is indeed what I've done ... a bit hard to maintain across a  
shared source code repository and multiple maven installations but it  
works.


Thanks Filip

-Luther



On Oct 5, 2008, at 6:12 PM, Filip S. Adamsen wrote:


It's not valid at all AFAIK.

I've changed it to use an RGB-value in my own version of T5.

-Filip

On 2008-10-05 20:12, Luther Baker wrote:

Ah ... I guess the t-palette-controls are something specific to IE:
I guess the color brown is not valid for a border?
-Luther
On Sun, Oct 5, 2008 at 1:07 PM, Luther Baker  
<[EMAIL PROTECTED]> wrote:

Were these CSS errors by chance fixed in 5.0.15?

http://jigsaw.w3.org/css-validator/validator?uri=http://www.effectiveprogramming.com/


http://www.effectiveprogramming.com/assets/tapestry/5.0.14/default.css 
 133DIV.t-beaneditorValue Error :
border <http://www.w3.org/TR/CSS21/box.html#propdef-border> brown  
is not a
color value : 2px outset brown 330 DIV.t-palette-controls  
BUTTON[disabled]
IMG Parse Error = 25 ) 331 DIV.t-palette-controls BUTTON[disabled]  
IMGProperty -moz-opacity doesn't exist :

0.25

Thanks,

-Luther




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: css validation

[Luther Baker]

Ah ... I guess the t-palette-controls are something specific to IE:
I guess the color brown is not valid for a border?

-Luther



On Sun, Oct 5, 2008 at 1:07 PM, Luther Baker <[EMAIL PROTECTED]> wrote:

> Were these CSS errors by chance fixed in 5.0.15?
>
> http://jigsaw.w3.org/css-validator/validator?uri=http://www.effectiveprogramming.com/
>
>
> http://www.effectiveprogramming.com/assets/tapestry/5.0.14/default.css 
> 133DIV.t-beaneditorValue Error :
> border <http://www.w3.org/TR/CSS21/box.html#propdef-border> brown is not a
> color value : 2px outset brown 330 DIV.t-palette-controls BUTTON[disabled]
> IMG Parse Error = 25 ) 331 DIV.t-palette-controls BUTTON[disabled] 
> IMGProperty -moz-opacity doesn't exist :
> 0.25
>
> Thanks,
>
> -Luther
>
>

css validation

[Luther Baker]

Were these CSS errors by chance fixed in 5.0.15?
http://jigsaw.w3.org/css-validator/validator?uri=http://www.effectiveprogramming.com/


http://www.effectiveprogramming.com/assets/tapestry/5.0.14/default.css133
DIV.t-beaneditorValue Error :
border brown
is not a color value : 2px outset brown330DIV.t-palette-controls
BUTTON[disabled] IMGParse Error = 25 )331DIV.t-palette-controls
BUTTON[disabled] IMGProperty -moz-opacity doesn't exist : 0.25

Thanks,

-Luther