Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy

[David E Jones-2]

It's interesting that we need this. It is probably common enough that  
maybe we should change the groovy event handler to automatically put  
it in the context.

Also, does anyone know what the "ExampleFeatureOptions" screen in the  
ExampleFeatureScreens.xml file is meant to be used for? It doesn't  
seem to be referred to anywhere, and it points to a script that  
doesn't seem to exist, and an ftl file that doesn't seem to exist...

-David


On Jun 21, 2008, at 8:10 PM, [hidden email] wrote:

> Author: lektran
> Date: Sat Jun 21 19:10:26 2008
> New Revision: 670298
>
> URL: http://svn.apache.org/viewvc?rev=670298&view=rev
> Log:
> Fix after groovy migration
>
> Modified:
>    ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/
> includes/FindExampleFeatures.groovy
>
> Modified: ofbiz/trunk/framework/example/webapp/example/WEB-INF/
> actions/includes/FindExampleFeatures.groovy
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy?rev=670298&r1=670297&r2=670298&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/
> includes/FindExampleFeatures.groovy (original)
> +++ ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/
> includes/FindExampleFeatures.groovy Sat Jun 21 19:10:26 2008
> @@ -25,6 +25,7 @@
> import org.ofbiz.entity.condition.EntityFunction;
> import org.ofbiz.entity.condition.EntityOperator;
>
> +delegator = request.getAttribute("delegator");
>
> andExprs = [];
> fieldValue = request.getParameter("exampleFeatureId");
>
>

[Scott Gray]

+1 on the event handler.

I would say the screen is a left over fragment from the ajax autocomplete
commits.

While we're (sort of) on the  topic of the autocomplete, does anybody really
find the following intuitive?
<field name="exampleFeatureId" id-name="exampleFeatureId">
    <text/>
    <on-field-event-update-area event-type="change"
area-id="exampleFeatureId" area-target="findExampleFeatures"/>
</field>

Also why would you want to search on an id field?  Wouldn't the description
be more appropriate?  I would have rather seen something like this:
<field name="exampleFeatureId">
  <drop-down>
    <server-options target="findExampleFeatures"
search-field="description"/>
  </drop-down>
</field>

- Scott

2008/6/22 David E Jones <[hidden email]>:

>
> It's interesting that we need this. It is probably common enough that maybe
> we should change the groovy event handler to automatically put it in the
> context.
>
> Also, does anyone know what the "ExampleFeatureOptions" screen in the
> ExampleFeatureScreens.xml file is meant to be used for? It doesn't seem to
> be referred to anywhere, and it points to a script that doesn't seem to
> exist, and an ftl file that doesn't seem to exist...
>
> -David
>
>
>
> On Jun 21, 2008, at 8:10 PM, [hidden email] wrote:
>
>  Author: lektran
>> Date: Sat Jun 21 19:10:26 2008
>> New Revision: 670298
>>
>> URL: http://svn.apache.org/viewvc?rev=670298&view=rev
>> Log:
>> Fix after groovy migration
>>
>> Modified:
>>
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>>
>> Modified:
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy?rev=670298&r1=670297&r2=670298&view=diff
>>
>> ==============================================================================
>> ---
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>> (original)
>> +++
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>> Sat Jun 21 19:10:26 2008
>> @@ -25,6 +25,7 @@
>> import org.ofbiz.entity.condition.EntityFunction;
>> import org.ofbiz.entity.condition.EntityOperator;
>>
>> +delegator = request.getAttribute("delegator");
>>
>> andExprs = [];
>> fieldValue = request.getParameter("exampleFeatureId");
>>
>>
>>
>

[Jacques Le Roux]

From: "Scott Gray" <[hidden email]>
> +1 on the event handler.

 +1 on the event handler too, surprising, I thought it was not needed.

> I would say the screen is a left over fragment from the ajax autocomplete
> commits.

I rewrote this Grovvy file which has been only renamed previously at my changes. I did not find a way to test it and thought it was
a work in progress so I did not remove it.

> While we're (sort of) on the  topic of the autocomplete, does anybody really
> find the following intuitive?
> <field name="exampleFeatureId" id-name="exampleFeatureId">
>    <text/>
>    <on-field-event-update-area event-type="change"
> area-id="exampleFeatureId" area-target="findExampleFeatures"/>
> </field>

Clearly not : on-field-event-update-area ... heu... long ?

Jacques

> Also why would you want to search on an id field?  Wouldn't the description
> be more appropriate?  I would have rather seen something like this:
> <field name="exampleFeatureId">
>  <drop-down>
>    <server-options target="findExampleFeatures"
> search-field="description"/>
>  </drop-down>
> </field>
>
> - Scott
>
> 2008/6/22 David E Jones <[hidden email]>:
>
>>
>> It's interesting that we need this. It is probably common enough that maybe
>> we should change the groovy event handler to automatically put it in the
>> context.
>>
>> Also, does anyone know what the "ExampleFeatureOptions" screen in the
>> ExampleFeatureScreens.xml file is meant to be used for? It doesn't seem to
>> be referred to anywhere, and it points to a script that doesn't seem to
>> exist, and an ftl file that doesn't seem to exist...
>>
>> -David
>>
>>
>>
>> On Jun 21, 2008, at 8:10 PM, [hidden email] wrote:
>>
>>  Author: lektran
>>> Date: Sat Jun 21 19:10:26 2008
>>> New Revision: 670298
>>>
>>> URL: http://svn.apache.org/viewvc?rev=670298&view=rev
>>> Log:
>>> Fix after groovy migration
>>>
>>> Modified:
>>>
>>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>>>
>>> Modified:
>>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy?rev=670298&r1=670297&r2=670298&view=diff
>>>
>>> ==============================================================================
>>> ---
>>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>>> (original)
>>> +++
>>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>>> Sat Jun 21 19:10:26 2008
>>> @@ -25,6 +25,7 @@
>>> import org.ofbiz.entity.condition.EntityFunction;
>>> import org.ofbiz.entity.condition.EntityOperator;
>>>
>>> +delegator = request.getAttribute("delegator");
>>>
>>> andExprs = [];
>>> fieldValue = request.getParameter("exampleFeatureId");
>>>
>>>
>>>
>>
>

[Adrian Crum-2]

--- On Sun, 6/22/08, Scott Gray <[hidden email]> wrote:

> While we're (sort of) on the  topic of the
> autocomplete, does anybody really
> find the following intuitive?
> <field name="exampleFeatureId"
> id-name="exampleFeatureId">
>     <text/>
>     <on-field-event-update-area
> event-type="change"
> area-id="exampleFeatureId"
> area-target="findExampleFeatures"/>
> </field>

The ajax stuff is still being developed. One thing that was suggested was to have an additional attribute to describe the type of server-side action:

<on-field-event-update-area
  event-type="change"
  area-id="exampleFeatureId"
  area-target="findExampleFeatures"
  server-action="autocomplete"/>

I can't think of a better element name. It's expressing "On a field event, update an area of the screen."

The event type (in the HTML world) would be either change or click.

The area id is the area (HTML container) to be updated when the event occurs.

The area target is the URL called to update the area specified in area-id.

The server action is a description of what type of response the server will put in the area.

If anyone has suggestions for better names, then this is a good time to make them - before we get any further into Ajax development. Just keep in mind that the syntax shouldn't be Ajax-specific - because the widgets are intended to support more than one rendering format. Also keep in mind that more than one ajax event can be triggered by a field event.

-Adrian



     

[Scott Gray]

Hi Adrian

Thanks for explanation, but isn't an autocomplete something that could just
as easily be used in a swing environment?  I don't see anything about it's
behaviour that is ajax specific.  The more I think about it I see can't why
we don't just have an autocomplete element, all we'd be telling the platform
specific renderer to do is take the user input and search a list of values
for any matches then show them to the user so they can select one.

Regards
Scott

2008/6/23 Adrian Crum <[hidden email]>:

> --- On Sun, 6/22/08, Scott Gray <[hidden email]> wrote:
> > While we're (sort of) on the  topic of the
> > autocomplete, does anybody really
> > find the following intuitive?
> > <field name="exampleFeatureId"
> > id-name="exampleFeatureId">
> >     <text/>
> >     <on-field-event-update-area
> > event-type="change"
> > area-id="exampleFeatureId"
> > area-target="findExampleFeatures"/>
> > </field>
>
> The ajax stuff is still being developed. One thing that was suggested was
> to have an additional attribute to describe the type of server-side action:
>
> <on-field-event-update-area
>  event-type="change"
>  area-id="exampleFeatureId"
>  area-target="findExampleFeatures"
>   server-action="autocomplete"/>
>
> I can't think of a better element name. It's expressing "On a field event,
> update an area of the screen."
>
> The event type (in the HTML world) would be either change or click.
>
> The area id is the area (HTML container) to be updated when the event
> occurs.
>
> The area target is the URL called to update the area specified in area-id.
>
> The server action is a description of what type of response the server will
> put in the area.
>
> If anyone has suggestions for better names, then this is a good time to
> make them - before we get any further into Ajax development. Just keep in
> mind that the syntax shouldn't be Ajax-specific - because the widgets are
> intended to support more than one rendering format. Also keep in mind that
> more than one ajax event can be triggered by a field event.
>
> -Adrian
>
>
>
>
>

[David E Jones]

There is actually an alternate way of doing autocomplete that is  
easier, and for now both will exist as the opinions and discussions  
around them have diverged.

On the drop-down element in the form widget there is a "type"  
attribute that has two option: "traditional", "auto-complete-server".  
The "traditional" one is the default. If you set it to "auto-complete-
server" then it will render a text box and when you start typing it  
will do a server-side autocomplete and show options based on what has  
been typed in.

The design goals are these:

1. setting this attribute is all that needs to be done to do an  
autocomplete
2. it is a variation of the drop-down because the query constraints to  
use in the autocomplete are the same as are needed for a drop-down;  
when the auto-complete query is done these constraints will be used  
plus one additional constraint to filter the displayed fields  
(according to the content of the description shown in drop-down/
autocomplete box)
3. no custom code is required; a generic event will be the target of  
the background server request and it will simply include the name of  
the form and the name of the field and the partial text entered as  
parameters, leaving all control of the query constraints in the form  
definition (ie on the drop-down element with the type="auto-complete-
server" attribute); for more security the session would be used with a  
key added as a session attribute that would be specified in a request  
parameter and used to look the field and form names in the session  
(preset by the form widget while rendering); that is important because  
security is normally controlled in views using screen section  
conditions, and those would be skipped when getting autocomplete  
options, opening the door to spoofing parameters

In general the idea with the form and screen widgets are to make  
things as easy as possible, requiring no additional programming to  
have access to features, just specify the options desired.

The XSD has been modified for the above, and someone was going to work  
on implementing this after the initial commit to the XSD, but I guess  
it hasn't been finished yet (I took at peek at the  
ModelFormField.DropDown class and didn't see anything there yet).

-David



On Jun 22, 2008, at 1:40 PM, Scott Gray wrote:

> Hi Adrian
>
> Thanks for explanation, but isn't an autocomplete something that  
> could just
> as easily be used in a swing environment?  I don't see anything  
> about it's
> behaviour that is ajax specific.  The more I think about it I see  
> can't why
> we don't just have an autocomplete element, all we'd be telling the  
> platform
> specific renderer to do is take the user input and search a list of  
> values
> for any matches then show them to the user so they can select one.
>
> Regards
> Scott
>
> 2008/6/23 Adrian Crum <[hidden email]>:
>
>> --- On Sun, 6/22/08, Scott Gray <[hidden email]> wrote:
>>> While we're (sort of) on the  topic of the
>>> autocomplete, does anybody really
>>> find the following intuitive?
>>> <field name="exampleFeatureId"
>>> id-name="exampleFeatureId">
>>>   <text/>
>>>   <on-field-event-update-area
>>> event-type="change"
>>> area-id="exampleFeatureId"
>>> area-target="findExampleFeatures"/>
>>> </field>
>>
>> The ajax stuff is still being developed. One thing that was  
>> suggested was
>> to have an additional attribute to describe the type of server-side  
>> action:
>>
>> <on-field-event-update-area
>> event-type="change"
>> area-id="exampleFeatureId"
>> area-target="findExampleFeatures"
>> server-action="autocomplete"/>
>>
>> I can't think of a better element name. It's expressing "On a field  
>> event,
>> update an area of the screen."
>>
>> The event type (in the HTML world) would be either change or click.
>>
>> The area id is the area (HTML container) to be updated when the event
>> occurs.
>>
>> The area target is the URL called to update the area specified in  
>> area-id.
>>
>> The server action is a description of what type of response the  
>> server will
>> put in the area.
>>
>> If anyone has suggestions for better names, then this is a good  
>> time to
>> make them - before we get any further into Ajax development. Just  
>> keep in
>> mind that the syntax shouldn't be Ajax-specific - because the  
>> widgets are
>> intended to support more than one rendering format. Also keep in  
>> mind that
>> more than one ajax event can be triggered by a field event.
>>
>> -Adrian
>>
>>
>>
>>
>>

[Scott Gray]

Thanks David, that sounds great, I'll get to work on it.

Regards
Scott

2008/6/23 David E Jones <[hidden email]>:

>
> There is actually an alternate way of doing autocomplete that is easier,
> and for now both will exist as the opinions and discussions around them have
> diverged.
>
> On the drop-down element in the form widget there is a "type" attribute
> that has two option: "traditional", "auto-complete-server". The
> "traditional" one is the default. If you set it to "auto-complete-server"
> then it will render a text box and when you start typing it will do a
> server-side autocomplete and show options based on what has been typed in.
>
> The design goals are these:
>
> 1. setting this attribute is all that needs to be done to do an
> autocomplete
> 2. it is a variation of the drop-down because the query constraints to use
> in the autocomplete are the same as are needed for a drop-down; when the
> auto-complete query is done these constraints will be used plus one
> additional constraint to filter the displayed fields (according to the
> content of the description shown in drop-down/autocomplete box)
> 3. no custom code is required; a generic event will be the target of the
> background server request and it will simply include the name of the form
> and the name of the field and the partial text entered as parameters,
> leaving all control of the query constraints in the form definition (ie on
> the drop-down element with the type="auto-complete-server" attribute); for
> more security the session would be used with a key added as a session
> attribute that would be specified in a request parameter and used to look
> the field and form names in the session (preset by the form widget while
> rendering); that is important because security is normally controlled in
> views using screen section conditions, and those would be skipped when
> getting autocomplete options, opening the door to spoofing parameters
>
> In general the idea with the form and screen widgets are to make things as
> easy as possible, requiring no additional programming to have access to
> features, just specify the options desired.
>
> The XSD has been modified for the above, and someone was going to work on
> implementing this after the initial commit to the XSD, but I guess it hasn't
> been finished yet (I took at peek at the ModelFormField.DropDown class and
> didn't see anything there yet).
>
> -David
>
>
>
>
> On Jun 22, 2008, at 1:40 PM, Scott Gray wrote:
>
>  Hi Adrian
>>
>> Thanks for explanation, but isn't an autocomplete something that could
>> just
>> as easily be used in a swing environment?  I don't see anything about it's
>> behaviour that is ajax specific.  The more I think about it I see can't
>> why
>> we don't just have an autocomplete element, all we'd be telling the
>> platform
>> specific renderer to do is take the user input and search a list of values
>> for any matches then show them to the user so they can select one.
>>
>> Regards
>> Scott
>>
>> 2008/6/23 Adrian Crum <[hidden email]>:
>>
>>  --- On Sun, 6/22/08, Scott Gray <[hidden email]> wrote:
>>>
>>>> While we're (sort of) on the  topic of the
>>>> autocomplete, does anybody really
>>>> find the following intuitive?
>>>> <field name="exampleFeatureId"
>>>> id-name="exampleFeatureId">
>>>>  <text/>
>>>>  <on-field-event-update-area
>>>> event-type="change"
>>>> area-id="exampleFeatureId"
>>>> area-target="findExampleFeatures"/>
>>>> </field>
>>>>
>>>
>>> The ajax stuff is still being developed. One thing that was suggested was
>>> to have an additional attribute to describe the type of server-side
>>> action:
>>>
>>> <on-field-event-update-area
>>> event-type="change"
>>> area-id="exampleFeatureId"
>>> area-target="findExampleFeatures"
>>> server-action="autocomplete"/>
>>>
>>> I can't think of a better element name. It's expressing "On a field
>>> event,
>>> update an area of the screen."
>>>
>>> The event type (in the HTML world) would be either change or click.
>>>
>>> The area id is the area (HTML container) to be updated when the event
>>> occurs.
>>>
>>> The area target is the URL called to update the area specified in
>>> area-id.
>>>
>>> The server action is a description of what type of response the server
>>> will
>>> put in the area.
>>>
>>> If anyone has suggestions for better names, then this is a good time to
>>> make them - before we get any further into Ajax development. Just keep in
>>> mind that the syntax shouldn't be Ajax-specific - because the widgets are
>>> intended to support more than one rendering format. Also keep in mind
>>> that
>>> more than one ajax event can be triggered by a field event.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>

[Scott Gray]

2008/6/22 David E Jones <[hidden email]>:

>
> It's interesting that we need this. It is probably common enough that maybe
> we should change the groovy event handler to automatically put it in the
> context.


Added in rev. 671503

Also, does anyone know what the "ExampleFeatureOptions" screen in the
> ExampleFeatureScreens.xml file is meant to be used for? It doesn't seem to
> be referred to anywhere, and it points to a script that doesn't seem to
> exist, and an ftl file that doesn't seem to exist...
>

Removed  in rev. 671504

Regards
Scott



On Jun 21, 2008, at 8:10 PM, [hidden email] wrote:

>
>  Author: lektran
>> Date: Sat Jun 21 19:10:26 2008
>> New Revision: 670298
>>
>> URL: http://svn.apache.org/viewvc?rev=670298&view=rev
>> Log:
>> Fix after groovy migration
>>
>> Modified:
>>
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>>
>> Modified:
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy?rev=670298&r1=670297&r2=670298&view=diff
>>
>> ==============================================================================
>> ---
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>> (original)
>> +++
>> ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
>> Sat Jun 21 19:10:26 2008
>> @@ -25,6 +25,7 @@
>> import org.ofbiz.entity.condition.EntityFunction;
>> import org.ofbiz.entity.condition.EntityOperator;
>>
>> +delegator = request.getAttribute("delegator");
>>
>> andExprs = [];
>> fieldValue = request.getParameter("exampleFeatureId");
>>
>>
>>
>