no, it's a part thing.  the part has to be able to reproduce itself
without depending on surrounding variables/methods.  someone with
better knowledge of part internals probably can give a better
workaround than I can (only thing I can think of would make all this
effort pointless so I'm not going to even bother posting it).

On Apr 28, 12:57 pm, Henry Baragar <[email protected]>
wrote:
> Kevin,
>
> I figured out that the "skip" attribute works nicely:
>
>     <engagement-table:collection_name skip="player" />
>
> when using the following definition:
>
>     <def tag="engagement-table">
>         <table fields="player match collectable ..." merge >
>     </def>
>
> That is, I added both "first" columns and skip either one or the other.
>
> However, if I change the definition as follows:
>
>     <def tag="engagement-table">
>         <div part="engagement-table">
>             <table fields="player match collectable ..." merge >
>         </div>
>     </def>
>
> I get the following error message:
>
>     undefined method `attributes' for #<ActionView::Base:0x7f06a128e638>
>
> Am I doing something wrong?  Or is there a bug code generated for the
> "part" attribute?
>
> Regards,
> Henry
>
>
>
> kevinpfromnm wrote:
> > well, a simple wrapper tag like I showed should do it then.  just, do
> > the merge on the table tag inside it so you can pass customizations on
> > to the table tag.
>
> > On Apr 27, 4:43 pm, Henry Baragar <[email protected]>
> > wrote:
>
> >> I would not call it an order requirement:  all the fields are the same,
> >> with the exception of the first one.  And yes, I want to avoid having to
> >> re-enter the field list.
>
> >> Henry
>
> >> ps.  There is quite a bit of savings because I stripped out the other
> >> dozen lines that would obscure the essence of the problem.  HB
>
> >> kevinpfromnm wrote:
>
> >>> damnit, didn't see the order requirement.  still the same, just
> >>> override the fields= on one of the calls.
>
> >>> again though, unless you've got more customization than in your
> >>> example, you're not saving much.
>
> >>> On Apr 27, 3:17 pm, kevinpfromnm <[email protected]> wrote:
>
> >>>> sure, though if it's only a generic table you're not getting much
> >>>> savings.
> >>>> <def tag="engagement-table">
> >>>>   <table fields="player, collectable..." merge />
> >>>> </def>
> >>>> then just call <engagement-table:collection_name_goes_here /> in the
> >>>> appropriate place.
>
> >>>> On Apr 27, 12:28 pm, Henry Baragar <[email protected]>
> >>>> wrote:
>
> >>>>> Sorry about the subject line, but I could not come up with a better
> >>>>> description...
>
> >>>>> I have the following models (for a sports league application):
>
> >>>>>     * Play
> >>>>>           o belongs to Player
> >>>>>           o belongs to Engagement
> >>>>>           o has score, field1, field2, etc.
> >>>>>     * Player
> >>>>>           o has many match_record, class name of Play
> >>>>>     * Engagement
> >>>>>           o has many line_up, class name of Play
>
> >>>>> I need to show following information in two tables:
>
> >>>>>    1. engagement, score, field1, field2, etc.
> >>>>>    2. player, score, field1, field2, etc.
>
> >>>>> Where the first one is for the match_record on the player show page and
> >>>>> the second one is for the line_up on the engagements page.
>
> >>>>> As you can see, its really the same information.  The only differences 
> >>>>> are:
>
> >>>>>    1. which collection to use
> >>>>>    2. which first column to use
>
> >>>>> Is it possible to define a tag that nicely handles both tables?
>
> >>>>> Regards,
> >>>>> Henry
>
> >>>>> ps.  Here is the relevant code I am using for both tables:
>
> >>>>>    1. On the players show page:
> >>>>>           * <table:match_record fields="engagement, collectable,
> >>>>>             collected, owing" />
> >>>>>    2. On the engagements show page:
> >>>>>           * <table:line_up fields="player, collectable, collected, 
> >>>>> owing" />
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google 
> >>>>> Groups "Hobo Users" group.
> >>>>> To post to this group, send email to [email protected].
> >>>>> To unsubscribe from this group, send email to 
> >>>>> [email protected].
> >>>>> For more options, visit this group 
> >>>>> athttp://groups.google.com/group/hobousers?hl=en.
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google 
> >>>> Groups "Hobo Users" group.
> >>>> To post to this group, send email to [email protected].
> >>>> To unsubscribe from this group, send email to 
> >>>> [email protected].
> >>>> For more options, visit this group 
> >>>> athttp://groups.google.com/group/hobousers?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "Hobo Users" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to 
> >> [email protected].
> >> For more options, visit this group 
> >> athttp://groups.google.com/group/hobousers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Hobo Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/hobousers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Hobo 
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/hobousers?hl=en.

Reply via email to