No problem! It's always a mystery until it isn't :)
Dave
On Tue, Oct 26, 2010 at 3: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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
