On 05 Mar 05:59, Emma wrote: > > > By computing a different colspan makeshift class (col-md-x) during form > > > creation > > > > That's colspan. > > How will be managed the "fill" and "expand". > > For example: > > > > <form col="4"> > > <field name="small" xfill="1"/> > > <field name="larger" xfill="1" xexpand="1"/> > > <field name="larger" xfill="1" xexpand="1"/> > > <field name="small" xfill="1"/> > > </form> > > > > should be displayed: > > > > ------------------------------------------------ > > |small| larger | larger |small| > > ------------------------------------------------ > > > > So far in the poc, each item is included inside a div. > xfill => 100% of the element iside the div > xepand => would act on the div containing the element (min-with/max-width + > width !important instead of fixed % width used for now) and eventually > weighting the computed colspan argument when a row is not full
But how will they be aligned?
|small| larger | larger |small|
|small| larger | larger |small|
| colspan3 |small |small|
| colspan3 |small|
> That's the idea I have, now as I said, it needs implementing and testing.
> Anf if it doesn't work, I guess we can use that part of the "resize"
> javascript already written
I tested a lot of possibilities before writing the resize function but
all my attempt did not worked for all cases. The best test cases are the
party form, the invoice/sale/purchase forms.
As I said at the TUB2013, form me the resize method renders exactly the
same way as the GTK included the same glitch.
Also for history, we want to have the same rendering because we want to
use the same definition of the view (same XML). And we don't want to have
to test on both application to be sure it renders as we expect. And
finaly, we don't want to have to introduce hacks in the views to make
them works correctly and nicely on both application.
--
Cédric Krier - B2CK SPRL
Email/Jabber: [email protected]
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
pgpNBtTYrUPP3.pgp
Description: PGP signature
