I access my *data* objects all the time in Tapestry templates. Things
such as firstName and lastName. The point I was trying to make is if
setFirstName started returning the 'User' instance instead of 'void',
it could possibly break some libraries out there (such as whatever
Tapestry uses to process t:value="person.firstName"), which would be
bad. Even if we tested Tapestry's accessors, there is no guarantee it
wouldn't break some other framework.
I never access my query objects directly in the template; I was mainly
talking about data objects and do we extend chainability to them.
Thanks,
mrg
On Thu, Oct 9, 2014 at 9:32 PM, Robert Zeigler
<robert.zeig...@roxanemy.com> wrote:
> It would only break tapestry of you were accessing properties of your query
> object from your template or via property expressions in bindings. So if your
> component had a limit property that was bound to the query's limit, then that
> might break.
>
> GATAATGCTATTTCTTTAATTTTCGAA
>
>> On Oct 9, 2014, at 2:08 PM, Michael Gentry <mgen...@masslight.net> wrote:
>>
>> Yeah, I don't know if changing setXyz to *not* return 'void' would
>> break things (like Tapestry). That would be a huge downer.
>>
>>> On Thu, Oct 9, 2014 at 3:03 PM, Andrus Adamchik <and...@objectstyle.org>
>>> wrote:
>>> I thought of that. Unfortunately "setXyz" is a 'java bean' setter, so we'll
>>> be redefining one of the most established Java conventions.
>>>
>>> Andrus
>>>
>>>> On Oct 9, 2014, at 2:51 PM, Michael Gentry <mgen...@masslight.net> wrote:
>>>>
>>>> I don't know if it will be confusing or not. At least with the
>>>> current method names, I can type query.set[ctrl+space] and let Eclipse
>>>> give me a list of set* method names to choose from (same applies for
>>>> get*), but that option won't be available with the new chainable API.
>>>> Part of me thinks just make setFetchLimit() return 'this' (at least
>>>> where it makes sense to preserve existing API):
>>>>
>>>> query.setFetchLimit(100).setDistinct(true);
>>>>
>>>> You could continue that in the model objects, too:
>>>>
>>>> person.setFirstName("John").setLastName("Doe");
>>>>
>>>> mrg
>>>>
>>>>
>>>>> On Thu, Oct 9, 2014 at 1:31 PM, Andrus Adamchik <and...@objectstyle.org>
>>>>> wrote:
>>>>>
>>>>>> On Oct 7, 2014, at 9:30 PM, Michael Gentry <mgen...@masslight.net> wrote:
>>>>>>
>>>>>> On Tue, Oct 7, 2014 at 6:44 PM, Aristedes Maniatis <a...@maniatis.org>
>>>>>> wrote:
>>>>>>>> That said, if returning this is the direction we're going, then really
>>>>>>>> all
>>>>>>>> the currently void methods in SelectQuery should do the same thing -
>>>>>>>> like
>>>>>>>> addOrdering for example.
>>>>>>>
>>>>>>>
>>>>>>> Correct, but we also need to gracefully deprecate the old methods and
>>>>>>> make new fluent ones.
>>>>>>
>>>>>> I was looking at the changes and was wondering if we really need to
>>>>>> deprecate the old methods. Can't setFetchLimit() live along with
>>>>>> limit()?
>>>>>
>>>>> I suspect having both will be rather confusing. Initially I even wanted
>>>>> to leave SelectQuery alone and implement all the new ideas in a separate
>>>>> query class (ObjectQuery?), but since we've already made a bunch of
>>>>> changes to SelectQuery in the same direction, I ended up with a massive
>>>>> change to the existing class.
>>>>>
>>>>> Andrus
>>>
