Issue Details (XML | Word | Printable)

Key: TRAILS-70
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alejandro Scandroli
Reporter: Ken in nashua
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Trails

Property Editors need GROUP support (ie. multicolumn properties)

Created: 20/Jun/07 05:45 PM   Updated: 07/Apr/08 11:34 AM
Component/s: trails-core
Affects Version/s: 1.1.0
Fix Version/s: 1.2.0

Time Tracking:
Not Specified

Environment: all


 Description  « Hide
See thread text below...

Hi Ken,

More than a year ago I needed to group properties for one of my projects.
I came to the conclusion that it was easier to customize each edit
page than try to make some generic @Group annotation.
Back then (and now too) the main issue was that the ObjectForm
component doesn't allow content, so customizations inside it without
using the Block component weren't possible. I came up with a
component called EmptyForm (I remember Chris making fun of my bad
taste for naming components ) that allow this type of
customizations. We can file a jira issue for this one, I will see if I
can find it.

Ass for the css, you can group editors in two columns using classes
"right" and "left". Take a look at the appfuse's edit user page html
markup (I would have posted a link to it but the appduse's demos
server is down) you can do the same in Trails.
If you need more columns you will need to write your own code. Anyway
this is impossible without the EmptyForm component

Alejandro.

On 6/20/07, Ken nashua <nhhockeyplayer@hotmail.com> wrote:
Guys,

Since we have housing for property editors... Is there support to group
multiple editors into a specific column oriented layour on same row of
specified multiple rows?

Currently all our properties are rendered in single column.

Does a GROUP property editor spark any ideas as a mechanism by which
multiple properties could gracefully be specified.

For instance I would like to render 3 columns of blobs on the same row...
optional label omitted too.

Can this be nipped in css since it could be layout related?

Trying to figure out a win/win for this little thing.

Any thoughts or ideas are appreciated.

Best regards
Ken in nashua



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Alejandro Scandroli added a comment - 21/Jun/07 03:25 AM - edited
I couldn't find the old component, but that's ok, it's not hard at all to do it again.

We have two options:
1) a completely new component

2) add two new parameters to the ObjectForm: renderBody & renderProperties
By default they will be renderBody = false, renderProperties = true, which will work like the current behavior.
Then you can use renderBody = true, renderProperties = false and you will get the EmptyForm behavior.
And finally renderBody = true, renderProperties = true, a new behavior that will allow you to add new code between the last automagically rendered property (@EditProperties) and the buttons (@ObjectActions).
renderBody = false, renderProperties = false is useless.

ideas? preferences?


Ken in nashua added a comment - 21/Jun/07 09:48 AM
Thanks Alejandro,

Can you elaborate on the new component option #1 ?

Rather than complicate the ObjectForm with new logic, what would the anatomy of this new component be?

For the sake of isolating logic and de-coupling I thought it might be nice to keep it segregated to it's own component in case it takes on any additional growth/functionality. Plus it would be retro-fittable to other combinations of components potentially.

How do you think about that?

Are there more details you could elaborate on the component itself?

Thank you


Alejandro Scandroli added a comment - 21/Jun/07 12:33 PM
The new component will have the renderBody = true, renderProperties = false behavior.
It should be simple and it should look like this:

<span jwcid="$content$">
<form jwcid="form" >
<span jwcid="@RenderBody"/>
<br/>
<div jwcid="objectActions" />
</form>
</span>

I will go ahead with this, so I can show you an elaborated usage example. We can merged with the ObjectForm later if we want to.


Alejandro Scandroli added a comment - 25/Nov/07 02:45 PM
I decided to implement it using a variation of option #2 (it's less code)
I've created two new parameters in the ObjectForm component
<parameter name="renderProperties" default-value="true"/>
	<parameter name="renderActions" default-value="true"/>

The ObjectForm template is self-explanatory:

<span jwcid="$content$">
	<form jwcid="form">
		<ul class="glasslist">
			<div jwcid="@If" condition="ognl:renderProperties">
				<div jwcid="editProperties"/>
			</div>
			<div jwcid="@If" condition="ognl:bodyCount &gt; 0">
				<span jwcid="@RenderBody"/>
			</div>
			<div jwcid="@If" condition="ognl:renderActions">
				<li class="buttonBar bottom">
					<div jwcid="objectActions"/>
				</li>
			</div>
		</ul>
	</form>
</span>

Another difference with the previous ObjectForm is that the new one will ALWAYS render its body if it has one.
You can find a usage example in PersonEdit.html in the "simple" example.