It's been that way for a few years at least, you can see what is made
available in ScreenRenderer.populateContextForRequest() and in turn
populateBasicContext().
Regarding entity-one the code looks for the primary keys in the
parameters map first and then looks in the context itself, if anything
is found in the context then that overrides what was found in the
parameters map.
Regards
Scott
2008/8/18 ian tabangay <[EMAIL PROTECTED]>:
> oh. sorry my version must have been very far from the recent release. in
> that case, the partyId field (from the line <set field="partyId"
> value="${userLogin.partyId}"/>) isnt visible from <entity-one>. I believe
> entity-one uses the fields in the parameters map by default? And setting the
> userLogin.partyId to partyId field isnt the same as setting it to
> parameters.partyId. (sorry im used to an end of May build. I wanted to help
> but Im not that familiar with the changes)
>
>
> ~ ian
>
> On Mon, Aug 18, 2008 at 1:43 PM, Scott Gray <[EMAIL PROTECTED]> wrote:
>
>> Hi Ian
>>
>> 2008/8/18 ian tabangay <[EMAIL PROTECTED]>:
>> > At least from
>> > the snippet that you provided, userLogin is not defined anywhere. If
>> youre
>> > intention was to retrieve the userLogin value of the currently logged in
>> > account, then you should retrieve the partyId this way:
>> > <set field="partyId" value="${*parameters.*userLogin.partyId}"/>
>>
>> userLogin is automatically put in the screen's context in the same way
>> that the parameters map automatically get builts out of the request
>> parameters and attrributes, session parameters etc.
>>
>> Regards
>> Scott
>>
>
