Re: opinion on modal dialog
2011-08-12 23:52, Vangel V. Ajanovski: Hi Christian, I looked into this in more detail, but I don't really understand what kind of validation problems are you preventing with the two zones (so efectively you have surrounded the form with three extra divs, and I have just two. div dialogzone div dialoglayout div newproviderzone form I may be wrong but I think when you have the zone=gridZone on the form and there are (server-side) validation failures, you won't see them because only the grid is refreshed, not the form. That's why i pack my form in a separate zone. The other thing is that I prefer to create a component for the dialog. So the structure is: div dialogzone div dialog With dialog component consisting of div formzone form - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: opinion on modal dialog
On 08/13/2011 10:35 AM, Christian Köberl wrote: I may be wrong but I think when you have the zone=gridZone on the form and there are (server-side) validation failures, you won't see them because only the grid is refreshed, not the form. OK, thanks I will check if this is the case. I thought I would solve all this with separating the zones completely. smime.p7s Description: S/MIME Cryptographic Signature
Re: opinion on modal dialog
On 08/09/2011 07:47 PM, Christian Köberl wrote: Another difference is that we use a different zone for the form in the dialog to prevent problems with server-side validation. Hi Christian, I looked into this in more detail, but I don't really understand what kind of validation problems are you preventing with the two zones (so efectively you have surrounded the form with three extra divs, and I have just two. div dialogzone div dialoglayout div newproviderzone form smime.p7s Description: S/MIME Cryptographic Signature
Re: opinion on modal dialog
2011-08-07 14:18, Vangel V. Ajanovski:
In the past I have used the modal window from ChenilleKit, and recently
I read the post from Taha on Java Magic blog, but I wanted to create
something simpler, preferably without additional custom JavaScript code
- just CSS and Tapestry zones.
I think that's a good idea - we're doing something similar.
The difference is that we're always creating a separate component for
the dialog - for this dialogs we have a DialogLayout component that
guarantees the layout and css.
Another difference is that we use a different zone for the form in the
dialog to prevent problems with server-side validation.
Here are some parts of our code, here for a new button:
Page.tml:
a t:id=newProvider${message:button.newProvider}/a
div t:id=dialogZone
t:block
div t:id=someOtherDialog /
div t:id=newProviderDialog /
/t:block
/div
-- here goes the grid with the data
Page.java
@Component(parameters = {zone=dialogZone})
private EventLink newProvider;
@OnEvent(newProvider)
Object newProvider()
{
return newProviderDialog;
}
NewProviderDialog.tml
div t:type=DialogLayout title=message:NewProviderDialog.title
div t:id=newProviderZone
form t:type=form zone=newProviderZone
div t:id=errors/
div t:id=newProviderEditor /
a t:id=save${message:button.save}/a
/form
/div
/div
NewProviderDialog.java
@OnEvent(success)
Object saveNewProvider()
{
// backen call
orderFacade.createNewProvider(provider);
// return page to refresh whole page
return componentResources.getPage();
}
--
Chris
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
opinion on modal dialog
In the past I have used the modal window from ChenilleKit, and recently
I read the post from Taha on Java Magic blog, but I wanted to create
something simpler, preferably without additional custom JavaScript code
- just CSS and Tapestry zones.
This is what I did, and I want to hear about any opinion if I will have
problems with it. The use-case is: a page shows a grid based on a
complex database view, and I want to edit underlying data that will
change the grid contents, but the data itself is not directly part of
the objects in the grid, so direct inPlace editing is not a suitable
usecase.
t:zone t:id=editingZone
t:if test=objectToEditInModal
div class=backgroundoverlay
div class=modalwindow
form t:id=editingForm zone=gridZonethis form is used to edit the
relevant data
t:submit
/form
/div
/div
/t:if
/t:zone
t:zone t:id=gridZone
t:grid . add=editing
p:editingCellt:actionlink id=editDataLink context=rowObject
zone=editingZone /
/t:grid
/t:zone
And in Java:
@Property
@Persist(FLASH)
private SomeClass objectToEditInModal;
public Object onActionFromEditDataLink(SomeClass rowObject) {
objectToEditInModal = rowObject;
return editingZone.getBody();
}
public Object onSelectedFromCancelButton() {
objectToEditInModal = null;
return editingZone.getBody();
}
@CommitAfter
public Object onSuccessFromEditingForm() {
doSomeThingWithData(objectToEditInModal);
objectToEditInModal = null;
return new
MultiZoneUpdate(editingZone,editingZone),add(gridZone, gridZone);
}
So on clicking the EditDataLink in the grid, the editingzone will be
updated, and because the value of the objectToEditInModal is no longer
null, the inside DIVs and FORM will be displayed.
If I click OK in the editingform then in Success it will change the data
and set the objectToEdit to null, so after refreshing the two zones, the
modal DIVs and the editingForm will be stripped from the HTML and
finally everything will be commited.
If I click Cancel then just objectToEdit is nulled and just the editing
zone will be refreshed leaving the grid intact, but because the null
value, the modal DIVs and the editingForm will be stripped from the HTML.
Finally, how it will look like depends on CSS so here it is:
.backgroundoverlay {
visibility: visible;
position: fixed;
left: 0px;
top: 0px;
width: 100%;
height: 100%;
z-index: 0;
background-image: url(/upisi/images/background-plasma-transparent.png);
}
.modalwindow {
width: 300px;
margin: 200px auto;
background-color: #fff;
border: 1px solid #000;
padding: 15px;
-moz-border-radius: 15px;
border-radius: 15px;
-moz-box-shadow: 2px 2px 8px #000;
-webkit-box-shadow: 2px 2px 8px #000;
box-shadow: 2px 2px 12px #000;
border:2px solid #DDF;
-webkit-box-shadow:
3px 3px 6px rgba(0, 0, 0, .2),
0px 0px 3px rgba(0, 0, 0, .1),
inset 0px 25px 25px #DDF;
}
I tried it with several browsers and it looked ok. It is very important
for the z-index to be 0, in order for tapestry validation boxes to be
shown in front. Do you see any problem with this?
This approach works for me. With many test cases that I did for a single
admin user it was OK.
One problem that I see is if many users edit the same data and same page
at the same time, I will need to constantly refresh the grid to show the
latest data, and I might need some locking.
But in my case this will not happen, there will be just few admins
dealing with separate subsets of the data with proper filtering.
Maybe there are some other problems, especially with how tapestry works,
so that's why I need an opinion.
smime.p7s
Description: S/MIME Cryptographic Signature
