Dave/Peter,
Was the issue resolved due to names of methods and properties not matching?
Curious,
Ashlon
On Tue, Oct 26, 2010 at 2:42 PM, Peter Bliznak <pbliz...@gmail.com> wrote:
> Yep, got it ... I really didn't realize that method of referring to stuff
> on
> OLGN stack could make such a difference.
> All works now, thanks Dave!
>
>
>
> On Tue, Oct 26, 2010 at 3:23 PM, Dave Newton <davelnew...@gmail.com>
> wrote:
>
> > And I told you why you're having that problem. The difference between
> > your code ("doesn't work") and Ying's code ("does work") tells you the
> > same thing. And if you understand how things like the <s:iterator...>
> > tag work, you understand why it displays correctly, even though it
> > fails on the submit. Yes?
> >
> > Dave
> >
> > On Tue, Oct 26, 2010 at 3:12 PM, Peter Bliznak <pbliz...@gmail.com>
> wrote:
> > > In the email above I was typing fast ans made mistakes but in code I
> have
> > > everything OK.
> > > As I`ve said I can load list and show all records and column with
> > checkboxes
> > > is displayed correctly as well.
> > > It is only when I try to get list back after submit I have problem.
> > >
> > >
> > > On Tue, Oct 26, 2010 at 3:05 PM, Dave Newton <davelnew...@gmail.com>
> > wrote:
> > >
> > >> Your names are wrong; if you're trying to reference a property of a
> > >> member in a list, you need to reference the list--how else would it
> > >> know what it's supposed to set? Think of OGNL names the exact same way
> > >> you'd use a Java name.
> > >>
> > >> The type conversion documentation covers this (somewhat obliquely,
> > >> IMO), as do both books you mentioned.
> > >>
> > >> Dave
> > >>
> > >> On Tue, Oct 26, 2010 at 2:36 PM, Peter Bliznak <pbliz...@gmail.com>
> > wrote:
> > >> > Nope........basically first line in the action is to call getter on
> > that
> > >> > list and it is already null ..... man :-(
> > >> >
> > >> > On Tue, Oct 26, 2010 at 2:33 PM, satyanarayana katta
> > >> > <saty.pra...@gmail.com>wrote:
> > >> >
> > >> >> R u by any chance creating the new list in the action class. If so
> > it
> > >> >> won't work and u will get null.
> > >> >>
> > >> >> Sent from my iPhone
> > >> >>
> > >> >> On Oct 26, 2010, at 10:23 AM, Peter Bliznak <pbliz...@gmail.com>
> > wrote:
> > >> >>
> > >> >> > Opps...damn gmail.
> > >> >> >
> > >> >> > As I've said I am using pretty much same approach as it was
> > suggested
> > >> >> above
> > >> >> > by the other poster.
> > >> >> > I have list:
> > >> >> > private List<WorkOrderTask> workOrderTaskList;
> > >> >> >
> > >> >> > with getter and setter'
> > >> >> >
> > >> >> > EAch : WorkOrderTask have :
> > >> >> > Long id;
> > >> >> > boolean completed ;// checkbox
> > >> >> >
> > >> >> > with getters and setter's
> > >> >> >
> > >> >> > in jsp iterate:
> > >> >> >
> > >> >> >
> > >> >> > <s:if test="workOrderTaskList.size() > 0">
> > >> >> > <s:iterator value="workOrderTask proceList" var="task"
> > >> >> > status="assetStatus">
> > >> >> > <tr class="listRow">
> > >> >> > <td ><s:checkbox theme="simple"
> > >> name="completed"
> > >> >> > fieldValue="%{#task.completed}" /> </td>
> > >> >> > <td ><p><s:property value="strDescription"
> > >> >> > /></p></td>
> > >> >> > so on....................
> > >> >> >
> > >> >> >
> > >> >> > at this stage I can display everything - all works including
> > >> checkboxes.
> > >> >> >
> > >> >> > Problem is when I submit and trying to retrive workOrderTaskList
> > >> inside
> > >> >> my
> > >> >> > action for futher processing - list is null - and I do have
> > >> getter/setter
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > On Tue, Oct 26, 2010 at 12:20 PM, Dave Newton <
> > davelnew...@gmail.com>
> > >> >> wrote:
> > >> >> >
> > >> >> >> This question has been asked and answered quite a few times. I
> > agree
> > >> >> >> the documentation should reflect this; as we're a volunteer
> group
> > all
> > >> >> >> assistance is appreciated. Feel free to file a CLA and update
> the
> > >> docs
> > >> >> >> to accurately reflect current behavior, and add entries to the
> FAQ
> > if
> > >> >> >> it addresses a typical pain point.
> > >> >> >>
> > >> >> >> And my book specifically *did* address many types of best
> > practices,
> > >> >> >> but mine, like all other books, have a limited number of pages,
> > and
> > >> >> >> which information is included/excluded is not always up to the
> > >> author.
> > >> >> >>
> > >> >> >> The reason the docs for checkbox don't address this typical case
> > is
> > >> >> >> because it has nothing specifically to do with checkboxes.
> > >> >> >>
> > >> >> >> If you're having a specific issue, post your code,
> configuration,
> > and
> > >> >> >> Struts version, otherwise we can't really help.
> > >> >> >>
> > >> >> >> Dave
> > >> >> >>
> > >> >> >> On Tue, Oct 26, 2010 at 11:59 AM, Peter Bliznak <
> > pbliz...@gmail.com>
> > >> >> >> wrote:
> > >> >> >>> Listen I googled quite a while before I asked here and all I
> saw
> > was
> > >> >> sea
> > >> >> >> of
> > >> >> >>> lost souls asking same question dating back to 2007...but NOT
> > >> >> >> answers...if
> > >> >> >>> it is so simple and obvious then why docs for checkbox are not
> > >> >> mentioning
> > >> >> >>> this trivial case. ...... BTW would you please point me to the
> > site
> > >> >> where
> > >> >> >>> there is nicely organized reading on Best Struts2
> Practices....I
> > >> will
> > >> >> >> truly
> > >> >> >>> appreciate it. (S2 in Action didn't mention and book written by
> > guy
> > >> >> with
> > >> >> >>> similar same like yours neither....aside from that Ive' read 3
> > >> >> >> more...guess
> > >> >> >>> what... nobody mentioned it anywhere)
> > >> >> >>>
> > >> >> >>> On Tue, Oct 26, 2010 at 7:54 AM, Dave Newton <
> > davelnew...@gmail.com
> > >> >
> > >> >> >> wrote:
> > >> >> >>>
> > >> >> >>>> Oh, I understand. Definitely agree; I think the OP just isn't
> > aware
> > >> of
> > >> >> >>>> some S2 functionality and/or best practices, that's all.
> > >> >> >>>>
> > >> >> >>>> Dave
> > >> >> >>>>
> > >> >> >>>> On Tuesday, October 26, 2010, Li Ying <
> liying.cn.2...@gmail.com
> > >
> > >> >> wrote:
> > >> >> >>>>> I mean:
> > >> >> >>>>>
> > >> >> >>>>> Representing associated data by a DTO class and then holding
> > DTO
> > >> >> >>>>> instances in one List
> > >> >> >>>>>
> > >> >> >>>>> is better than
> > >> >> >>>>>
> > >> >> >>>>> Holding data in several separated Lists each represent one
> > column.
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>>> 2010/10/26 Dave Newton <davelnew...@gmail.com>:
> > >> >> >>>>>> On Tue, Oct 26, 2010 at 4:32 AM, Li Ying wrote:
> > >> >> >>>>>>> I think this is a better design, because the data modal is
> > more
> > >> >> >>>>>>> compliant with OO principles.
> > >> >> >>>>>>
> > >> >> >>>>>> Better than what?
> > >> >> >>>>>>
> > >> >> >>>>>> (And as an aside, there's nothing particularly OO about
> what's
> > >> >> >>>>>> essentially a struct, although from a pragmatic viewpoint,
> > >> >> >>>>>> particularly when doing data transfer, sometimes such
> > constructs
> > >> >> seem
> > >> >> >>>>>> reasonable. See http://c2.com/cgi/wiki?DumbDataObject for a
> > >> brief
> > >> >> >>>>>> discussion.)
> > >> >> >>>>>>
> > >> >> >>>>>> Dave
> > >> >> >>>>>
> > >> >> >>>>>
> > >> ---------------------------------------------------------------------
> > >> >> >>>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > >> >> >>>>> For additional commands, e-mail: user-h...@struts.apache.org
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>>>
> > >> ---------------------------------------------------------------------
> > >> >> >>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > >> >> >>>> For additional commands, e-mail: user-h...@struts.apache.org
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>
> > >> >> >>
> > >> >> >>
> > ---------------------------------------------------------------------
> > >> >> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > >> >> >> For additional commands, e-mail: user-h...@struts.apache.org
> > >> >> >>
> > >> >> >>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > >> >> For additional commands, e-mail: user-h...@struts.apache.org
> > >> >>
> > >> >>
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > >> For additional commands, e-mail: user-h...@struts.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > For additional commands, e-mail: user-h...@struts.apache.org
> >
> >
>
