Hi
It sounds like you are attempting to do something in a way that may not be
ideal (judging from all the hoops you are trying to jump through).
In Tapestry you can usually get really far using the simple building blocks
that are provided. With a few exceptions you are usually taking a bad
course, when you think you need to write all kinds of weird code to make
the framework happy (Exceptions are usually things like when the (complex)
built-in components like grid and tree does not support what you need).
You seem to have a somewhat unclear understanding of component rendering
and form submissions, that could be a place to start. (Hint. take a look at
the Form component
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/Form.html
- That is the one that triggers those prepare* events etc, there is no
magic going on in pages with respect to that. As events bubble "up" through
containers, you should not expect your component to receive those events if
it is _inside_ the form. If you want something complex acting like a form
element, use Thiagos suggestion).
I would recommend against trying to implement some kind of pub/sub
mechanism to circumvent the fact that you feel your components are
misbehaving because events bubble up... - It may be possible to get
something to work, but with respect to maintenance and component
re-usability you will most likely end up realizing that you have shoot
yourself in the foot, at some point.
With a few exceptions, I would generally say that using @Persist in
components is a smell, instead pass the information as a parameter - Pages
are ultimately the things driving the components, they should worry about
how to configure the components (if that means that a value should be
persisted, it should happen in the page).
Also if you find yourself needing page life-cycle callbacks in your
component (e.g my component should do this on activate or similar, you are
doing it wrong)
It is hard to come up with something concrete based on the info provided,
but I guess that if you realize how form submission and component render
life cycles interact, it will be easier to fix your problem.
--
Chris
On Thu, Nov 1, 2018 at 3:53 PM abangkis wrote:
> Hi Thiago,
>
> This component is some ui that we extract from few common pages. It shows a
> series of tabs. Each tabs has its own related Hibernate Entity. We don't
> pass all the tabs entity as parameter to the component. Instead we just
> pass the root component and let the rest of the tab get their entity from
> the DAO injected to the component.
>
> The component is encapsulated inside of a form. It works well showing the
> data for each tab. But when we submit the form we receive that error. Since
> the tabs Hibernate Entity is not Persist in the component. Our approach is
> to use @Persist only when we have to. Usually this is handled in the page
> by populating the tabs Hibernate Entities in the page OnPrepare method.
> Translating this approach from a page implementation to the custom
> component isn't as straight forward as I thought. Since OnPrepare isn't
> called in the custom component. (it's part of page life cycle but not part
> of component rendering lifecycle?)
>
> Tried to implement it using Process Submission example from jumpstart
> (since it seems that's how you implement a component that contribute the
> value to form submission process). But still haven't got it working yet.
>
> By the way. Is it common to have @Persist property inside of a component?
> How do you clean the persisted field after submission? Is it enough only by
> calling ComponentResources.discardPersistentField() on the page OnSucces
> method? Or do we need to clean it up on the Component Java code instead?
>
> Sorry if the explanation a bit long and confusing. Thanks.
>
>
>
>
>
>
> On Thu, Nov 1, 2018 at 8:41 PM Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
> > Hello!
> >
> > What exactly is this component trying to do? I couldn't get it by looking
> > at your code snippet.
> >
> > Anyway, the probably best way of doing it if you want to create a
> component
> > which edits something is to subclass AbstractField.
> >
> > The error message says you're trying to pass a null object to BeanDisplay
> > while it renders, so this doesn't seem to be a problem with form
> submission
> > at all, but a problem while rendering the page later.
> >
> > Failure reading parameter 'source' of component
> > common/loan/ApplicationSummary:loanbundleedittabs2.beandisplay_0.loop:
> > Parameter 'object' of component
> > common/loan/ApplicationSummary:loanbundleedittabs2.beandisplay_0 is bound
> >
> >
> > On Thu, Nov 1, 2018 at 4:43 AM abangkis wrote:
> >
> > > Hai guys, still working on my custom component.
> > >
> > > How do we let our custom component participate in form submission.
> > > Apparently there is no onPrepare hook for tapestry custom component.
> > >
