You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <jo...@undersunconsulting.com> on 2008/06/22 09:15:41 UTC
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
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, lektran@apache.org 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");
>
>
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by Scott Gray <le...@gmail.com>.
2008/6/22 David E Jones <jo...@undersunconsulting.com>:
>
> 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, lektran@apache.org 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");
>>
>>
>>
>
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by Scott Gray <le...@gmail.com>.
Thanks David, that sounds great, I'll get to work on it.
Regards
Scott
2008/6/23 David E Jones <jo...@hotwaxmedia.com>:
>
> 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 <ad...@yahoo.com>:
>>
>> --- On Sun, 6/22/08, Scott Gray <le...@gmail.com> 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
>>>
>>>
>>>
>>>
>>>
>>>
>
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by David E Jones <jo...@hotwaxmedia.com>.
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 <ad...@yahoo.com>:
>
>> --- On Sun, 6/22/08, Scott Gray <le...@gmail.com> 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
>>
>>
>>
>>
>>
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by Scott Gray <le...@gmail.com>.
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 <ad...@yahoo.com>:
> --- On Sun, 6/22/08, Scott Gray <le...@gmail.com> 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
>
>
>
>
>
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sun, 6/22/08, Scott Gray <le...@gmail.com> 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
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Scott Gray" <le...@gmail.com>
> +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 <jo...@undersunconsulting.com>:
>
>>
>> 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, lektran@apache.org 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");
>>>
>>>
>>>
>>
>
Re: svn commit: r670298 - /ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/FindExampleFeatures.groovy
Posted by Scott Gray <le...@gmail.com>.
+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 <jo...@undersunconsulting.com>:
>
> 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, lektran@apache.org 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");
>>
>>
>>
>