How to autobind in this case?

[Demetrios Kyriakis]

Hi,

How to autobind in the following case?
from xxx-list.htm to xxx-edit.htm, the binding is done with a parameter, e.g. "String userName".
This works very nice.

The problem is when the parameter to bind is not in the xxx entity, but a in a related one, e.g., in User
, reached with "toUser.userName":
the table in xxx-list.htm is still rendered correctly with:
column.setDecorator(new LinkDecorator(table,links,"toUser.userName"));

but in xxx-edit.htm a parameter for autobinding like:
public String toUser.userName;
is impossible (in Java).

Also, if for the parameter to autobind, another parameter is used (e.g. "bindName", than there's the problem that it's value is not found, since "bindName" exists nowhere).

How to solve such situations?

Thank you,

Demetrios.

[Malcolm Edgar-2]

---------- Forwarded message ----------
From: Malcolm Edgar <malcolm.edgar@...>
Date: Fri, Jun 27, 2008 at 8:59 AM
Subject: Re: [Click-user] How to autobind in this case?
To: Demetrios Kyriakis <demetrios.kyriakis@...>


Hi Demetrios,

You can do path based binding of parameters in forms.

user.address.postcode

If the address object is null Click will create an Address object
instance using its public no-args constructor

This is documented in the Forms Javadoc under the Data Binding topic:

"Binding of nested data objects is supported using the OGNL library.
To use nested objects in your form, simply specify the object path as
the Field name. Note in the object path you exclude the root object,
so the path customer.address.state is specified as address.state.

When populating an object from a form post Click will automatically
create any null nested objects so their properties can be set. To do
this Click uses the no-args constructor of the nested objects class"

regards Malcolm Edgar

On Fri, Jun 27, 2008 at 7:18 AM, Demetrios Kyriakis
<demetrios.kyriakis@...> wrote:

>
> Hi,
>
> How to autobind in the following case?
> from xxx-list.htm to xxx-edit.htm, the binding is done with a parameter,
> e.g. "String userName".
> This works very nice.
>
> The problem is when the parameter to bind is not in the xxx entity, but a in
> a related one, e.g., in User
> , reached with "toUser.userName":
> the table in xxx-list.htm is still rendered correctly with:
> column.setDecorator(new LinkDecorator(table,links,"toUser.userName"));
>
> but in xxx-edit.htm a parameter for autobinding like:
> public String toUser.userName;
> is impossible (in Java).
>
> Also, if for the parameter to autobind, another parameter is used (e.g.
> "bindName", than there's the problem that it's value is not found, since
> "bindName" exists nowhere).
>
> How to solve such situations?
>
> Thank you,
>
> Demetrios.
> --
> View this message in context: http://www.nabble.com/How-to-autobind-in-this-case--tp18142390p18142390.html
> Sent from the click-user mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Click-user mailing list
> Click-user@...
> https://lists.sourceforge.net/lists/listinfo/click-user
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[sabob]

Auto-binding is a conventional method one can use to bind the fields
to request parameters. As long as you name your controls to the path
of the object graph it will work.

Keep in mind that the auto-binding is just a convention. If you have a
different convention (or want complete control) you can bind manually:

public MyPage extends Page {

   private Field someField = new Field("someValue");

   public void onInit() {

     Form form = new Form("form") {
       public void copyTo(Object bean) {
         Customer customer = (Customer) bean;
         customer.setFirstname(someField().getValue());
         ...
       }
       public void copyFrom(Object bean) {
         Customer customer = (Customer) bean;
         someField.setValue(customer.getFirstname());
         ...
       }
     }
   }
}

Its a manual process but binding is encapsulated inside the form.

kind regards

bob

Malcolm Edgar wrote:

> ---------- Forwarded message ----------
> From: Malcolm Edgar <malcolm.edgar@...>
> Date: Fri, Jun 27, 2008 at 8:59 AM
> Subject: Re: [Click-user] How to autobind in this case?
> To: Demetrios Kyriakis <demetrios.kyriakis@...>
>
>
> Hi Demetrios,
>
> You can do path based binding of parameters in forms.
>
> user.address.postcode
>
> If the address object is null Click will create an Address object
> instance using its public no-args constructor
>
> This is documented in the Forms Javadoc under the Data Binding topic:
>
> "Binding of nested data objects is supported using the OGNL library.
> To use nested objects in your form, simply specify the object path as
> the Field name. Note in the object path you exclude the root object,
> so the path customer.address.state is specified as address.state.
>
> When populating an object from a form post Click will automatically
> create any null nested objects so their properties can be set. To do
> this Click uses the no-args constructor of the nested objects class"
>
> regards Malcolm Edgar
>
> On Fri, Jun 27, 2008 at 7:18 AM, Demetrios Kyriakis
> <demetrios.kyriakis@...> wrote:
>> Hi,
>>
>> How to autobind in the following case?
>> from xxx-list.htm to xxx-edit.htm, the binding is done with a parameter,
>> e.g. "String userName".
>> This works very nice.
>>
>> The problem is when the parameter to bind is not in the xxx entity, but a in
>> a related one, e.g., in User
>> , reached with "toUser.userName":
>> the table in xxx-list.htm is still rendered correctly with:
>> column.setDecorator(new LinkDecorator(table,links,"toUser.userName"));
>>
>> but in xxx-edit.htm a parameter for autobinding like:
>> public String toUser.userName;
>> is impossible (in Java).
>>
>> Also, if for the parameter to autobind, another parameter is used (e.g.
>> "bindName", than there's the problem that it's value is not found, since
>> "bindName" exists nowhere).
>>
>> How to solve such situations?
>>
>> Thank you,
>>
>> Demetrios.
>> --
>> View this message in context: http://www.nabble.com/How-to-autobind-in-this-case--tp18142390p18142390.html
>> Sent from the click-user mailing list archive at Nabble.com.
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Click-user mailing list
>> Click-user@...
>> https://lists.sourceforge.net/lists/listinfo/click-user
>>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[Ahmed Mohombe]

> How to autobind in the following case?
> from xxx-list.htm to xxx-edit.htm, the binding is done with a parameter,
> e.g. "String userName".
> This works very nice.
>
> The problem is when the parameter to bind is not in the xxx entity, but a in
> a related one, e.g., in User
> , reached with "toUser.userName":
> the table in xxx-list.htm is still rendered correctly with:
> column.setDecorator(new LinkDecorator(table,links,"toUser.userName"));
>
> but in xxx-edit.htm a parameter for autobinding like:
> public String toUser.userName;
> is impossible (in Java).
>
> Also, if for the parameter to autobind, another parameter is used (e.g.
> "bindName", than there's the problem that it's value is not found, since
> "bindName" exists nowhere).
>
> How to solve such situations?

Hi Demetrios,

IMHO the simplest way to make your example to work is to add to LinkDecorator a new attribute called
"alias" or "idParameterAlias" (and a constructor parameter for convenience).
Than you would have in XXXList.java(xxx-list.htm) the follwing line:
======================
column.setDecorator(new LinkDecorator(table,links,"toUser.userName","aliasName"));
======================

and so the generated link to the XXXEdit.java(xxx-edit.htm) would look:
    /xxx-edit.htm?aliasName=myname
(instead of the actual and not very usable
    /xxx-edit.htm?toUser.userName=myname )

so that in XXXEdit.java(xxx-edit.htm) you can have a working "autobinding" just by using:
=======================
public String aliasName;
=======================

AFAIK the above situation happens quite often in real applications that have a few more entities and
a few more connections between them :).

Would this solve your problem?

If yes, please make a JIRA.
IMHO updating LinkDecorator with that attribute is trivial, so if the other developers have nothing
against it, I could make that update.

Ahmed.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[Demetrios Kyriakis]

Ahmed Mohombe wrote:

> How to autobind in the following case?
> from xxx-list.htm to xxx-edit.htm, the binding is done with a parameter,
> e.g. "String userName".
> This works very nice.
>
> The problem is when the parameter to bind is not in the xxx entity, but a in
> a related one, e.g., in User
> , reached with "toUser.userName":
> the table in xxx-list.htm is still rendered correctly with:
> column.setDecorator(new LinkDecorator(table,links,"toUser.userName"));
>
> but in xxx-edit.htm a parameter for autobinding like:
> public String toUser.userName;
> is impossible (in Java).
>
> Also, if for the parameter to autobind, another parameter is used (e.g.
> "bindName", than there's the problem that it's value is not found, since
> "bindName" exists nowhere).
>
> How to solve such situations?
IMHO the simplest way to make your example to work is to add to LinkDecorator a new attribute called
"alias" or "idParameterAlias" (and a constructor parameter for convenience).
Than you would have in XXXList.java(xxx-list.htm) the follwing line:
======================
column.setDecorator(new LinkDecorator(table,links,"toUser.userName","aliasName"));
======================

and so the generated link to the XXXEdit.java(xxx-edit.htm) would look:
    /xxx-edit.htm?aliasName=myname
(instead of the actual and not very usable
    /xxx-edit.htm?toUser.userName=myname )

so that in XXXEdit.java(xxx-edit.htm) you can have a working "autobinding" just by using:
=======================
public String aliasName;
=======================

Would this solve your problem?

Yes, it would. Thank you very much :):
public String aliasName;
is a valid Java construct, not like
public String toUser.userName;
so it works :).

Ahmed Mohombe wrote:

AFAIK the above situation happens quite often in real applications that have a few more entities and
a few more connections between them :).

You bet it happens :).
In many cases, a "natural key", like userName is used(or required) - not the primary key (or other number).

The problem is that the natural key usually has different names between "source" and "destination", so I think the idea to use an "alias" is great :).

Ahmed Mohombe wrote:

IMHO updating LinkDecorator with that attribute is trivial, so if the other developers have nothing
against it, I could make that update.

Do other the develpers agree with this addition?

I think this addition is very important, since parameters with non-numeric values in many public pages is a requirement: to prevent abuse (or just because of design or rewrite rules). Example:
/page.htm?id=X
is much much often abused than
/page.htm?alias=alphaValue
since X can be guessed very easily by bots or attackers.

Thank you,

Demetrios.

[sabob]

Hi,

This feature seems a little awkward. The auto-binding feature is
already difficult to understand because of the magic happening in the
background. Having LinkDecorator define aliases which binds to the
public Page properties will increase this complexity.

Might also open a can of worms for other controls to support aliases.

What would be nice is a blog entry with such a custom LinkDecorator,
which developers can copy/paste for their own applications.

kind regards

bob

Demetrios Kyriakis wrote:

>
> Ahmed Mohombe wrote:
>>> How to autobind in the following case?
>>> from xxx-list.htm to xxx-edit.htm, the binding is done with a parameter,
>>> e.g. "String userName".
>>> This works very nice.
>>>
>>> The problem is when the parameter to bind is not in the xxx entity, but a
>>> in
>>> a related one, e.g., in User
>>> , reached with "toUser.userName":
>>> the table in xxx-list.htm is still rendered correctly with:
>>> column.setDecorator(new LinkDecorator(table,links,"toUser.userName"));
>>>
>>> but in xxx-edit.htm a parameter for autobinding like:
>>> public String toUser.userName;
>>> is impossible (in Java).
>>>
>>> Also, if for the parameter to autobind, another parameter is used (e.g.
>>> "bindName", than there's the problem that it's value is not found, since
>>> "bindName" exists nowhere).
>>>
>>> How to solve such situations?
>> IMHO the simplest way to make your example to work is to add to
>> LinkDecorator a new attribute called
>> "alias" or "idParameterAlias" (and a constructor parameter for
>> convenience).
>> Than you would have in XXXList.java(xxx-list.htm) the follwing line:
>> ======================
>> column.setDecorator(new
>> LinkDecorator(table,links,"toUser.userName","aliasName"));
>> ======================
>>
>> and so the generated link to the XXXEdit.java(xxx-edit.htm) would look:
>>     /xxx-edit.htm?aliasName=myname
>> (instead of the actual and not very usable
>>     /xxx-edit.htm?toUser.userName=myname )
>>
>> so that in XXXEdit.java(xxx-edit.htm) you can have a working "autobinding"
>> just by using:
>> =======================
>> public String aliasName;
>> =======================
>>
>> Would this solve your problem?
>>
> Yes, it would. Thank you very much :):
> public String aliasName;
> is a valid Java construct, not like
> public String toUser.userName;
> so it works :).
>
>
> Ahmed Mohombe wrote:
>> AFAIK the above situation happens quite often in real applications that
>> have a few more entities and
>> a few more connections between them :).
>>
> You bet it happens :).
> In many cases, a "natural key", like userName is used(or required) - not the
> primary key (or other number).
>
> The problem is that the natural key usually has different names between
> "source" and "destination", so I think the idea to use an "alias" is great
> :).
>
>
> Ahmed Mohombe wrote:
>> IMHO updating LinkDecorator with that attribute is trivial, so if the
>> other developers have nothing
>> against it, I could make that update.
>>
> Do other the develpers agree with this addition?
>
> I think this addition is very important, since parameters with non-numeric
> values in many public pages is a requirement: to prevent abuse (or just
> because of design or rewrite rules). Example:
> /page.htm?id=X
> is much much often abused than
> /page.htm?alias=alphaValue
> since X can be guessed very easily by bots or attackers.
>
> Thank you,
>
> Demetrios.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[Ahmed Mohombe]

> This feature seems a little awkward. The auto-binding feature is
> already difficult to understand because of the magic happening in the
> background. Having LinkDecorator define aliases which binds to the
> public Page properties will increase this complexity.
>
> Might also open a can of worms for other controls to support aliases.
IMHO not (besides LinkDecorator is not a Control, just an utility class
- it's place would be better in "net.sf.click.extras.util" ).
Also "alias" is maybe not the right name for this: it's just that a property
can have different names in two pages (and this happens too often in applications I saw),
but it means the same thing e.g. "userName" (to identify/show the same thing).

This small improvement (that has minimal impact in LinkDecorator - 100% backward compatible)
allows the auto-binding to work in *all* cases.

> What would be nice is a blog entry with such a custom LinkDecorator,
> which developers can copy/paste for their own applications.
-1 for copy and paste repositories.
I guess, what needs more to be explaied in a blog entry (maybe with a nice diagram - like the actual
activity diagram) is auto-binding itself.

Ahmed.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[Ahmed Mohombe]

> This small improvement (that has minimal impact in LinkDecorator - 100% backward compatible)
> allows the auto-binding to work in *all* cases.
The code that does the trick is:
================
if(alias!=null)
    link.setParameter(alias, value.toString());
else
    link.setParameter(idProperty, value.toString());
=================
instead of the actual:

=================
link.setParameter(idProperty, value.toString());
=================
from LinkDecorator.java:462

or we could name "alias" to something like: "targetIdProperty".

Ahmed.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[Ahmed Mohombe]

>> IMHO updating LinkDecorator with that attribute is trivial, so if the
>> other developers have nothing
>> against it, I could make that update.
>>
> Do other the develpers agree with this addition?
It looks like the other developers don't really agree.

So I attached to this post for you, an example implementation (as
an extended class - not so nice like it would be just changing the LinkDecorator itself).

You can use it as it is: just change the package name to something you need.

Ahmed.
P.S. Tell me if it works for you.


package com.incorp.control;

import net.sf.click.extras.control.LinkDecorator;
import net.sf.click.control.Table;
import net.sf.click.control.AbstractLink;
import net.sf.click.control.ActionLink;
import net.sf.click.Context;

/**
 * Link decorator that accepts a target id with a different name than the source id.
 *
 */
public class AdvancedLinkDecorator extends LinkDecorator {
    protected String targetIdProperty;
   
    public AdvancedLinkDecorator(Table table, AbstractLink[] links, String idProperty) {
        super(table, links, idProperty);
    }
    public AdvancedLinkDecorator(Table table, AbstractLink[] links, String idProperty, String targetIdProperty) {
        super(table, links, idProperty);
        this.targetIdProperty = targetIdProperty;
    }

    protected void initLink(AbstractLink link, Context context, Object value) {
        link.setId(null);

        if (link instanceof ActionLink) {
            ((ActionLink) link).setValueObject(value);

        } else {
            if (value != null) {
                if(targetIdProperty!=null)
                    link.setParameter(targetIdProperty, value.toString());
                else
                    link.setParameter(idProperty, value.toString());
            }
        }

        link.setParameter(Table.PAGE, String.valueOf(table.getPageNumber()));

        if (table.getSortedColumn() != null) {
            link.setParameter(Table.COLUMN, table.getSortedColumn());
            link.setParameter(Table.ASCENDING, Boolean.toString(!table.isSortedAscending()));
            link.setParameter(Table.SORT, Boolean.toString(table.isSorted()));
        }        
    }
}

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

[Demetrios Kyriakis]

Ahmed Mohombe wrote:

>> IMHO updating LinkDecorator with that attribute is trivial, so if the
>> other developers have nothing
>> against it, I could make that update.
>>
> Do other the develpers agree with this addition?
It looks like the other developers don't really agree.

So I attached to this post for you, an example implementation (as
an extended class - not so nice like it would be just changing the LinkDecorator itself).

You can use it as it is: just change the package name to something you need.

Ahmed.
P.S. Tell me if it works for you.

Yes, it works very well. Thank you very much :).

I still think that it would be better if that small functionality improvement would be in LinkDecorator itself.

Demetrios.

[Malcolm Edgar-2]

+1 Ahmed,

Looks like a simple and worth while change.

regards Malcolm Edgar

On Sat, Jul 19, 2008 at 10:55 AM, Demetrios Kyriakis
<demetrios.kyriakis@...> wrote:

>
>
> Ahmed Mohombe wrote:
>>
>>>> IMHO updating LinkDecorator with that attribute is trivial, so if the
>>>> other developers have nothing
>>>> against it, I could make that update.
>>>>
>>> Do other the develpers agree with this addition?
>> It looks like the other developers don't really agree.
>>
>> So I attached to this post for you, an example implementation (as
>> an extended class - not so nice like it would be just changing the
>> LinkDecorator itself).
>>
>> You can use it as it is: just change the package name to something you
>> need.
>>
>> Ahmed.
>> P.S. Tell me if it works for you.
>>
> Yes, it works very well. Thank you very much :).
>
> I still think that it would be better if that small functionality
> improvement would be in LinkDecorator itself.
>
> Demetrios.
> --
> View this message in context: http://www.nabble.com/How-to-autobind-in-this-case--tp18142390p18540042.html
> Sent from the click-user mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Click-user mailing list
> Click-user@...
> https://lists.sourceforge.net/lists/listinfo/click-user
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user