Hello all,
As you know in the 2.1, if one adds or delete a field using the +/x button,
the sheet jumps back to the top every time.
That make geonetwork tool less user friendly for metadata contributors.
I have so many complain feedback coming from the users related with this
problems.
Is it planned to correct this part on the release 2.2 coming soon or in a
later release ?
Any solutions will be very appreciate 
Best regards Fabien Bachraty
--
View this message in context: http://www.nabble.com/Sheet-jumps-back-to-the-top-every-time-tp16466714s18419p16466714.html
Sent from the geonetwork-users mailing list archive at Nabble.com.
Hello,
I have testing the new release 2.2 for two days
This is great and thanks the Geonetwork team's, for the good work done.
But the problem of sheet jumping back to the top, is also present on this
release.
Personally, I'm a little surprising that their is no more people complaining
about this persisting problem.
My thinking is that this little problem is largely deprecating the tool for
metadata contributors. In fact this is not only my thinking, I report first
the feedback of the users of my project.
Expecting this post will resound better my first.one.
Best regards,
Fabien Bachraty
--
View this message in context: http://www.nabble.com/Sheet-jumps-back-to-the-top-every-time-tp16466714s18419p16558215.html
Sent from the geonetwork-users mailing list archive at Nabble.com.
FBachraty wrote:
Hello,
I have testing the new release 2.2 for two days
This is great and thanks the Geonetwork team's, for the good work done.
But the problem of sheet jumping back to the top, is also present on this
release.
Personally, I'm a little surprising that their is no more people complaining
about this persisting problem.
My thinking is that this little problem is largely deprecating the tool for
metadata contributors. In fact this is not only my thinking, I report first
the feedback of the users of my project.
Expecting this post will resound better my first.one.
Best regards,
Fabien Bachraty
Hi Fabien,
Plenty of people down here don't like it either! 
When you go to add a new element with the '+' button the form is submitted with the reference number of the parent element tacked on as an anchor to the action eg. #_64. When the screen is refreshed with the rebuilt form, the window is positioned at the anchor created for the parent element (ie. #_64) in the XSLTs. This approach works quite well when you're adding an element to a parent that doesn't have many children, but it fails if the parent is large or if the parent hasn't been rendered at all (as can happen if you've written you're own xslt for element processing/display in a profile say) - like you've said above.
I have a "fix" (well, ok, its kind of a hack) nearly sorted that works with the existing html forms but employs a different method to reposition the page more accurately after the html form is regenerated. On other editor stuff, some cheap speed ups can be had by employing Saxon, other speed ups (with more work associated) could be possible by profiling and then reworking some of the XSLT (possibly as XSLT2).
Alternatives to the html form approach are under investigation.
Cheers,
Simon
Nice to learn that there is some investigations about this problem
best regards,
Fabien Bachraty
Simon Pigot-5 wrote:
FBachraty wrote:
Hello,
I have testing the new release 2.2 for two days
This is great and thanks the Geonetwork team's, for the good work done.
But the problem of sheet jumping back to the top, is also present on this
release.
Personally, I'm a little surprising that their is no more people
complaining
about this persisting problem.
My thinking is that this little problem is largely deprecating the tool
for
metadata contributors. In fact this is not only my thinking, I report
first
the feedback of the users of my project.
Expecting this post will resound better my first.one.
Best regards,
Fabien Bachraty
Hi Fabien,
Plenty of people down here don't like it either! 
When you go to add a new element with the '+' button the form is
submitted with the reference number of the parent element tacked on as
an anchor to the action eg. #_64. When the screen is refreshed with the
rebuilt form, the window is positioned at the anchor created for the
parent element (ie. #_64) in the XSLTs. This approach works quite well
when you're adding an element to a parent that doesn't have many
children, but it fails if the parent is large or if the parent hasn't
been rendered at all (as can happen if you've written you're own xslt
for element processing/display in a profile say) - like you've said above.
I have a "fix" (well, ok, its kind of a hack) nearly sorted that works
with the existing html forms but employs a different method to
reposition the page more accurately after the html form is regenerated.
On other editor stuff, some cheap speed ups can be had by employing
Saxon, other speed ups (with more work associated) could be possible by
profiling and then reworking some of the XSLT (possibly as XSLT2).
Alternatives to the html form approach are under investigation.
Cheers,
Simon
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
--
View this message in context: http://www.nabble.com/Sheet-jumps-back-to-the-top-every-time-tp16466714s18419p16584384.html
Sent from the geonetwork-users mailing list archive at Nabble.com.