Re: Client-side validation - enhance to match server-side
Does anyone have any feedback on this patch? I don't expect it is perfect or complete, but I'd like to understand if this is the approach you'd expect for implementing this feature. https://issues.apache.org/jira/browse/ADFFACES-391 On 3/16/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, I've posted an initial patch so client-side validation matches server-side here: https://issues.apache.org/jira/browse/ADFFACES-391 Feedback gratefully received. Description: Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION /param-name param-valuetrue/param-value /context-param [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ] Danny Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson [16/Mar/07 08:59 AM] Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name param-valuetrue/param-value /context-param On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
OK, I've posted an initial patch so client-side validation matches server-side here: https://issues.apache.org/jira/browse/ADFFACES-391 Feedback gratefully received. Description: Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION /param-name param-valuetrue/param-value /context-param [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ] Danny Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson [16/Mar/07 08:59 AM] Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name param-valuetrue/param-value /context-param On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete -- Chordiant Software Inc. www.chordiant.com
Re: Getting the Component ID from within getOnclick()
Sorry, I should have been clearer. In the renderer code on the server-side my component overrides the XhtmlRenderer.getOnclick() to insert some custom javascript. Within this method I'd like to be able to call getClientId() on the component to grab the id. Currently I'm having to use eval combined with this.id to workaround this issue, but it's not very clean. Danny On 2/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Keeping in mind that I have barely a day's worth of practical javascript experience, maybe this.id or something along those lines? On 2/27/07, Danny Robinson [EMAIL PROTECTED] wrote: anyone ;-) On 2/23/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Any advice on how to easily retrieve the component ID from within an overridden method such as XhtmlRenderer.getOnclick(). The only parameter to this is FacesBean.Type, and not the component itself. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Client-side validation - enhance to match server-side
Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com
Re: Client-side validation - enhance to match server-side
I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com
Re: Getting the Component ID from within getOnclick()
anyone ;-) On 2/23/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Any advice on how to easily retrieve the component ID from within an overridden method such as XhtmlRenderer.getOnclick(). The only parameter to this is FacesBean.Type, and not the component itself. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Getting the Component ID from within getOnclick()
Guys, Any advice on how to easily retrieve the component ID from within an overridden method such as XhtmlRenderer.getOnclick(). The only parameter to this is FacesBean.Type, and not the component itself. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com
Re: Early Prototype - Dialog using DHTML / iFrame
Thanks Adam. I'm surprised it works at all on Safari, I don't have a Mac I can test on! So that's good news, even if it does need a tweak. I'll take a look at the overlap you mentioned. One the size issue, I looked (in firefox) at launchDialog.jspx and noticed that it still uses the windowWidth windowHeight attributes, which if you remove should resize to the content (at least it does for me). If you leave them in, then they just need to be increased. Danny On 2/7/07, Adam Winer [EMAIL PROTECTED] wrote: FWIW, a couple things I've noticed: - On Safari, the popups have no border or background; in the launchDialog.jspx demo, when you have two popups up together, the title for one popup actually overlaps the next (are they both being placed at the same z-order?) - The sizing algorithm doesn't seem to work that well - everything is a bit too small (Safari + Firefox). -- Adam On 2/6/07, Adam Winer [EMAIL PROTECTED] wrote: Committed this patch - thanks! -- Adam On 2/6/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, just uploaded an updated patch. Dialogs will now appear at a fixed size if specified, or will resize to that of the first dialog page and remain that size for all other pages. Started work on also removing frame redirect from date picker also. Danny. On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/3/07, Danny Robinson [EMAIL PROTECTED] wrote: uploaded patch to jira - including extra bits for setting the dialog title using BodyRenderer. Nice! A few quick questions also: Could we add the popup config entry to the trinidad config file rather than web.xml and allow it to use a value binding - this way we can test both from the same test/demo app? We've generally stuck to using trinidad-config basically for things that are on the RequestContext, and I don't think this is going to end up there. For the purposes of this branch, it'd be OK if the function that tested if popups were supported had something really goofy like: facesContext.getViewRoot().getViewId().contains(Popup) ... which'd be useful enough for testing, which is what this branch is for. Quick questions: Should we use the height/width properties as the master setting for the dialog size, and only resize to content if they were not set? I guess we wouldn't want to auto-resize to content in every situation, or would we want to always initially set it. Perhaps you use height/width as a minimum setting, and grow if they're not set. Or, height/width are an absolute rule. If we use the BodyRenderer approach to also set the dialog size, how do we ensure it doesn't keep resizing if the dialog runs to many pages? You could just stash a JS flag on the popup object; once resized, flip the flag and stop resizing. Also title will change as you move from page to page in dialog - I guess this is appropriate through. Yes, that's what you want. We have a few more options for closing dialogs also as the javascript component could even close modals if you clicked-off the dialog - in some instances this could be useful. Indeed, could be very useful! -- Adam On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, Could you attach that patch to http://issues.apache.org/jira/browse/ADFFACES-307? This is the more official way of doing things. -- Adam On 2/2/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/2/07, Danny Robinson [EMAIL PROTECTED] wrote: Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-). I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME Great! DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup ().setTitle( document.title);) which works for me. Thoughts? I was thinking we could rely on BodyRenderer; if we detect when we're inside of a dialog (perhaps by looking at pageFlowScope), and when we know
Re: Early Prototype - Dialog using DHTML / iFrame
OK, just uploaded an updated patch. Dialogs will now appear at a fixed size if specified, or will resize to that of the first dialog page and remain that size for all other pages. Started work on also removing frame redirect from date picker also. Danny. On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/3/07, Danny Robinson [EMAIL PROTECTED] wrote: uploaded patch to jira - including extra bits for setting the dialog title using BodyRenderer. Nice! A few quick questions also: Could we add the popup config entry to the trinidad config file rather than web.xml and allow it to use a value binding - this way we can test both from the same test/demo app? We've generally stuck to using trinidad-config basically for things that are on the RequestContext, and I don't think this is going to end up there. For the purposes of this branch, it'd be OK if the function that tested if popups were supported had something really goofy like: facesContext.getViewRoot().getViewId().contains(Popup) ... which'd be useful enough for testing, which is what this branch is for. Quick questions: Should we use the height/width properties as the master setting for the dialog size, and only resize to content if they were not set? I guess we wouldn't want to auto-resize to content in every situation, or would we want to always initially set it. Perhaps you use height/width as a minimum setting, and grow if they're not set. Or, height/width are an absolute rule. If we use the BodyRenderer approach to also set the dialog size, how do we ensure it doesn't keep resizing if the dialog runs to many pages? You could just stash a JS flag on the popup object; once resized, flip the flag and stop resizing. Also title will change as you move from page to page in dialog - I guess this is appropriate through. Yes, that's what you want. We have a few more options for closing dialogs also as the javascript component could even close modals if you clicked-off the dialog - in some instances this could be useful. Indeed, could be very useful! -- Adam On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, Could you attach that patch to http://issues.apache.org/jira/browse/ADFFACES-307? This is the more official way of doing things. -- Adam On 2/2/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/2/07, Danny Robinson [EMAIL PROTECTED] wrote: Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-). I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME Great! DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup ().setTitle( document.title);) which works for me. Thoughts? I was thinking we could rely on BodyRenderer; if we detect when we're inside of a dialog (perhaps by looking at pageFlowScope), and when we know that dialogs are configured to use popups, fire Javascript in the body's onload. If they don't want to use our body renderer, then they don't get this fun. BTW, always be very careful when getting a property off of parent... Wrap it in try/catch, because if the parent is in a different URL domain, you can get a security exception. - Implement sizing correctly Same as for title - we need to know when the iframe has finished loading. Interestingly I can't seem to get the trinidad-demo stuff to run as it has errors complaining about a null process scope. Anyway - it works in my own little web app using the add number demo and date picker. Hrm, when I get a chance to merge it in, I'll have a look. -- Adam Danny On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, I grabbed the patch, made a branch, and applied it. I fixed up some things: - Moved (almost) all of the popup dialog and panel popup JS code into TrPanelPopup and TrPopupDialog wrapper objects - Fix coding convention problems: no tabs allowed, braces on new lines - Instead of removing the code that launched new windows for dialogs, hide it behind a web.xml context init parameter (currently defaulting to the old style) - Use resource bundle
Re: Early Prototype - Dialog using DHTML / iFrame
uploaded patch to jira - including extra bits for setting the dialog title using BodyRenderer. A few quick questions also: Could we add the popup config entry to the trinidad config file rather than web.xml and allow it to use a value binding - this way we can test both from the same test/demo app? Quick questions: Should we use the height/width properties as the master setting for the dialog size, and only resize to content if they were not set? I guess we wouldn't want to auto-resize to content in every situation, or would we want to always initially set it. If we use the BodyRenderer approach to also set the dialog size, how do we ensure it doesn't keep resizing if the dialog runs to many pages? Also title will change as you move from page to page in dialog - I guess this is appropriate through. We have a few more options for closing dialogs also as the javascript component could even close modals if you clicked-off the dialog - in some instances this could be useful. Cheers, Danny On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, Could you attach that patch to http://issues.apache.org/jira/browse/ADFFACES-307? This is the more official way of doing things. -- Adam On 2/2/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/2/07, Danny Robinson [EMAIL PROTECTED] wrote: Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-). I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME Great! DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup().setTitle( document.title);) which works for me. Thoughts? I was thinking we could rely on BodyRenderer; if we detect when we're inside of a dialog (perhaps by looking at pageFlowScope), and when we know that dialogs are configured to use popups, fire Javascript in the body's onload. If they don't want to use our body renderer, then they don't get this fun. BTW, always be very careful when getting a property off of parent... Wrap it in try/catch, because if the parent is in a different URL domain, you can get a security exception. - Implement sizing correctly Same as for title - we need to know when the iframe has finished loading. Interestingly I can't seem to get the trinidad-demo stuff to run as it has errors complaining about a null process scope. Anyway - it works in my own little web app using the add number demo and date picker. Hrm, when I get a chance to merge it in, I'll have a look. -- Adam Danny On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, I grabbed the patch, made a branch, and applied it. I fixed up some things: - Moved (almost) all of the popup dialog and panel popup JS code into TrPanelPopup and TrPopupDialog wrapper objects - Fix coding convention problems: no tabs allowed, braces on new lines - Instead of removing the code that launched new windows for dialogs, hide it behind a web.xml context init parameter (currently defaulting to the old style) - Use resource bundle for translatable contents - Load JS automatically There's plenty to do still, most importantly: - Implement sizing correctly - Populate title of the popup based on the title of the dialog's content - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME But, that said: cool stuff! I think before we could look at merging anything into trunk, we'd need an Apache licensing agreement signed off on (because it's a non-trivial chunk of code...) -- Adam On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote: Patch file available here: http://thefoxberry.com/ Only note, is that this also contains the panelPopup component, and that you'll need to include the two .js files into the servlet that merges the common javascript. If I get chance later, I'll do this and repost the patch. Should work fine in Firefox or IE, others are untested. Danny On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote: I'll post up a .patch file later today. I used custom .js for the dialog, as I wasn't sure how we'd go about integrating a 3rd party lib, and the few I looked at didn't quite
Re: Early Prototype - Dialog using DHTML / iFrame
Adam,
Thanks for the cleanup, it was on my list, but I wanted feedback before
progressing.
I've pulled down the sandbox containing the changes, but it fails to build.
The plugins are OK, but main trinidad tree fails. Suggestions welcome.
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven
-jar-plugin:2.0
Cause: Cannot find setter nor field in
org.apache.maven.archiver.ManifestConfigu
ration for 'addDefaultSpecificationEntries'
Agreed there's plenty to do, but now it's in the sandbox it's easier.
Thanks,
Danny
On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote:
Danny,
I grabbed the patch, made a branch, and applied it. I fixed up
some things:
- Moved (almost) all of the popup dialog and panel popup JS code into
TrPanelPopup and TrPopupDialog wrapper objects
- Fix coding convention problems: no tabs allowed, braces on new lines
- Instead of removing the code that launched new windows for dialogs, hide
it behind a web.xml context init parameter (currently defaulting to the
old
style)
- Use resource bundle for translatable contents
- Load JS automatically
There's plenty to do still, most importantly:
- Implement sizing correctly
- Populate title of the popup based on the title of the dialog's content
- Most importantly, for popup-based dialogs, do not use a FRAMESET
inside of the IFRAME; just use the IFRAME
But, that said: cool stuff!
I think before we could look at merging anything into trunk,
we'd need an Apache licensing agreement signed off on (because
it's a non-trivial chunk of code...)
-- Adam
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Patch file available here: http://thefoxberry.com/
Only note, is that this also contains the panelPopup component, and that
you'll need to include the two .js files into the servlet that merges
the
common javascript. If I get chance later, I'll do this and repost the
patch.
Should work fine in Firefox or IE, others are untested.
Danny
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
I'll post up a .patch file later today.
I used custom .js for the dialog, as I wasn't sure how we'd go about
integrating a 3rd party lib, and the few I looked at didn't quite fit
right,
or had license issues. Besides, it was good practice. However, if we
have
a library that we're trying to integrate with on a larger scale, then
I
think it makes sense.
D.
On 1/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEy Danny,
two things;
1) the image looks great.
2) do you use one of these days upcoming ajax-ish JavaScript libs?
(or custom JS?)
Another one, will you also provide the source in somewhat format?
That would allow us to start with a sandbox ..
Thanks,
Matthias
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hey,
In a timely fashion, I've just seen Adams comments about wanting
to
switch
to a DHTML/iFrame solution for dialog windows.
I've pulled together a prototype set of changes that switches the
default
implementation of dialog windows, to use a floating popup
iframe. It
seems
to work well and both the date picker dialog and the number picker
demo work
without any alteration. It is implemented as a javascript
component
that
inherits from the basic panelPopup component I posted a while
back. The
prototype renders an iframe that blocks access to the parent
window
until
the dialog returns.
I say prototype, because I need some feedback on what is/isn't
allowed
to
change inside the current dialog framework. Meaning - do we have
to
introduce two modes of running, where dialogs will appear in
either a
browser window, or in a DHTML iframe? Could we kill off the
browser
window
version as there seems to be a very large amount of JavaScript
that we
could
tear out if we did.
I'll post a war file this afternoon demonstrating how it works,
but
for now
here's a quick picture and the list of changes.
http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg
DialogRequest.java modified to call an alternative javascript
method
for
opening the dhtml dialog. When the dialog is launched it is
populated
with
the necessary properties for callback when the dialog is closed,
thus
no
array of dialogs (var ADFDialogReturn = new Array()) needs to be
maintained.
function _launchPopupDialog(
srcURL,
features,
formName,
postbackId,
partial)
{
_theDialog.callback = _returnFromDialogAndSubmit;
_theDialog.callbackProps = { formNameKey:formName,
postbackKey:postbackId, partialKey:partial };
_theDialog.resize(features['height'], features['width']);
_theDialog.launchDialog(srcURL);
}
On close the dialog will call the following callback function
function _returnFromDialogAndSubmit(props, value) {
if (props
Re: Early Prototype - Dialog using DHTML / iFrame
I just commented out the offending entries in my pom.xml files and all seems
well now.
On 1/31/07, Danny Robinson [EMAIL PROTECTED] wrote:
Adam,
Thanks for the cleanup, it was on my list, but I wanted feedback before
progressing.
I've pulled down the sandbox containing the changes, but it fails to
build. The plugins are OK, but main trinidad tree fails. Suggestions
welcome.
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven
-jar-plugin:2.0
Cause: Cannot find setter nor field in
org.apache.maven.archiver.ManifestConfigu
ration for 'addDefaultSpecificationEntries'
Agreed there's plenty to do, but now it's in the sandbox it's easier.
Thanks,
Danny
On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote:
Danny,
I grabbed the patch, made a branch, and applied it. I fixed up
some things:
- Moved (almost) all of the popup dialog and panel popup JS code into
TrPanelPopup and TrPopupDialog wrapper objects
- Fix coding convention problems: no tabs allowed, braces on new lines
- Instead of removing the code that launched new windows for dialogs,
hide
it behind a web.xml context init parameter (currently defaulting to the
old
style)
- Use resource bundle for translatable contents
- Load JS automatically
There's plenty to do still, most importantly:
- Implement sizing correctly
- Populate title of the popup based on the title of the dialog's content
- Most importantly, for popup-based dialogs, do not use a FRAMESET
inside of the IFRAME; just use the IFRAME
But, that said: cool stuff!
I think before we could look at merging anything into trunk,
we'd need an Apache licensing agreement signed off on (because
it's a non-trivial chunk of code...)
-- Adam
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Patch file available here: http://thefoxberry.com/
Only note, is that this also contains the panelPopup component, and
that
you'll need to include the two .js files into the servlet that merges
the
common javascript. If I get chance later, I'll do this and repost the
patch.
Should work fine in Firefox or IE, others are untested.
Danny
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
I'll post up a .patch file later today.
I used custom .js for the dialog, as I wasn't sure how we'd go about
integrating a 3rd party lib, and the few I looked at didn't quite
fit right,
or had license issues. Besides, it was good practice. However, if
we have
a library that we're trying to integrate with on a larger scale,
then I
think it makes sense.
D.
On 1/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEy Danny,
two things;
1) the image looks great.
2) do you use one of these days upcoming ajax-ish JavaScript
libs?
(or custom JS?)
Another one, will you also provide the source in somewhat format?
That would allow us to start with a sandbox ..
Thanks,
Matthias
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hey,
In a timely fashion, I've just seen Adams comments about wanting
to
switch
to a DHTML/iFrame solution for dialog windows.
I've pulled together a prototype set of changes that switches
the
default
implementation of dialog windows, to use a floating popup
iframe. It
seems
to work well and both the date picker dialog and the number
picker
demo work
without any alteration. It is implemented as a javascript
component
that
inherits from the basic panelPopup component I posted a while
back. The
prototype renders an iframe that blocks access to the parent
window
until
the dialog returns.
I say prototype, because I need some feedback on what is/isn't
allowed
to
change inside the current dialog framework. Meaning - do we
have to
introduce two modes of running, where dialogs will appear in
either a
browser window, or in a DHTML iframe? Could we kill off the
browser
window
version as there seems to be a very large amount of JavaScript
that we
could
tear out if we did.
I'll post a war file this afternoon demonstrating how it works,
but
for now
here's a quick picture and the list of changes.
http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg
DialogRequest.java modified to call an alternative javascript
method
for
opening the dhtml dialog. When the dialog is launched it is
populated
with
the necessary properties for callback when the dialog is closed,
thus
no
array of dialogs (var ADFDialogReturn = new Array()) needs to be
maintained.
function _launchPopupDialog(
srcURL,
features,
formName,
postbackId,
partial)
{
_theDialog.callback = _returnFromDialogAndSubmit;
_theDialog.callbackProps = { formNameKey:formName
Early Prototype - Dialog using DHTML / iFrame
Hey,
In a timely fashion, I've just seen Adams comments about wanting to switch
to a DHTML/iFrame solution for dialog windows.
I've pulled together a prototype set of changes that switches the default
implementation of dialog windows, to use a floating popup iframe. It seems
to work well and both the date picker dialog and the number picker demo work
without any alteration. It is implemented as a javascript component that
inherits from the basic panelPopup component I posted a while back. The
prototype renders an iframe that blocks access to the parent window until
the dialog returns.
I say prototype, because I need some feedback on what is/isn't allowed to
change inside the current dialog framework. Meaning - do we have to
introduce two modes of running, where dialogs will appear in either a
browser window, or in a DHTML iframe? Could we kill off the browser window
version as there seems to be a very large amount of JavaScript that we could
tear out if we did.
I'll post a war file this afternoon demonstrating how it works, but for now
here's a quick picture and the list of changes.
http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg
DialogRequest.java modified to call an alternative javascript method for
opening the dhtml dialog. When the dialog is launched it is populated with
the necessary properties for callback when the dialog is closed, thus no
array of dialogs (var ADFDialogReturn = new Array()) needs to be maintained.
function _launchPopupDialog(
srcURL,
features,
formName,
postbackId,
partial)
{
_theDialog.callback = _returnFromDialogAndSubmit;
_theDialog.callbackProps = { formNameKey:formName,
postbackKey:postbackId, partialKey:partial };
_theDialog.resize(features['height'], features['width']);
_theDialog.launchDialog(srcURL);
}
On close the dialog will call the following callback function
function _returnFromDialogAndSubmit(props, value) {
if (props)
{
var formName = props['formNameKey'];
var postbackId = props['postbackKey'];
var partial = props['partialKey'];
if (partial)
_submitPartialChange(formName, 0, {rtrn:postbackId});
else
submitForm(formName, 0, {rtrn:postbackId});
}
}
CoreRenderKit.returnFromDialog() - modified to return the following
scriptlet, which closes the dialog and causes the above callback to occur.
scriptparent.parent.returnFromDialog();/script
Window.js - _sizeWin() function - disabled until I have time to rework. If
left untouched it resizes the window - which because the dialog is an iframe
means it resizes the main window.
Minor changes to DateField.js to call my dialog component rather than
openWindow, along with an additional callback function for passing the
selected date back to the parent component.
To Do:
Pass skinning keys to dialog javascript class so we can skin the dialog.
While it handles blocking clicks to parent, it doesn't handle keeping
keyboard nav inside the iframe.
Your thoughts please...
Danny
--
Chordiant Software Inc.
www.chordiant.com
Re: Early Prototype - Dialog using DHTML / iFrame
I'll post up a .patch file later today.
I used custom .js for the dialog, as I wasn't sure how we'd go about
integrating a 3rd party lib, and the few I looked at didn't quite fit right,
or had license issues. Besides, it was good practice. However, if we have
a library that we're trying to integrate with on a larger scale, then I
think it makes sense.
D.
On 1/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEy Danny,
two things;
1) the image looks great.
2) do you use one of these days upcoming ajax-ish JavaScript libs?
(or custom JS?)
Another one, will you also provide the source in somewhat format?
That would allow us to start with a sandbox ..
Thanks,
Matthias
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hey,
In a timely fashion, I've just seen Adams comments about wanting to
switch
to a DHTML/iFrame solution for dialog windows.
I've pulled together a prototype set of changes that switches the
default
implementation of dialog windows, to use a floating popup iframe. It
seems
to work well and both the date picker dialog and the number picker demo
work
without any alteration. It is implemented as a javascript component
that
inherits from the basic panelPopup component I posted a while back. The
prototype renders an iframe that blocks access to the parent window
until
the dialog returns.
I say prototype, because I need some feedback on what is/isn't allowed
to
change inside the current dialog framework. Meaning - do we have to
introduce two modes of running, where dialogs will appear in either a
browser window, or in a DHTML iframe? Could we kill off the browser
window
version as there seems to be a very large amount of JavaScript that we
could
tear out if we did.
I'll post a war file this afternoon demonstrating how it works, but for
now
here's a quick picture and the list of changes.
http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg
DialogRequest.java modified to call an alternative javascript method for
opening the dhtml dialog. When the dialog is launched it is populated
with
the necessary properties for callback when the dialog is closed, thus no
array of dialogs (var ADFDialogReturn = new Array()) needs to be
maintained.
function _launchPopupDialog(
srcURL,
features,
formName,
postbackId,
partial)
{
_theDialog.callback = _returnFromDialogAndSubmit;
_theDialog.callbackProps = { formNameKey:formName,
postbackKey:postbackId, partialKey:partial };
_theDialog.resize(features['height'], features['width']);
_theDialog.launchDialog(srcURL);
}
On close the dialog will call the following callback function
function _returnFromDialogAndSubmit(props, value) {
if (props)
{
var formName = props['formNameKey'];
var postbackId = props['postbackKey'];
var partial = props['partialKey'];
if (partial)
_submitPartialChange(formName, 0, {rtrn:postbackId});
else
submitForm(formName, 0, {rtrn:postbackId});
}
}
CoreRenderKit.returnFromDialog() - modified to return the following
scriptlet, which closes the dialog and causes the above callback to
occur.
scriptparent.parent.returnFromDialog();/script
Window.js - _sizeWin() function - disabled until I have time to
rework. If
left untouched it resizes the window - which because the dialog is an
iframe
means it resizes the main window.
Minor changes to DateField.js to call my dialog component rather than
openWindow, along with an additional callback function for passing the
selected date back to the parent component.
To Do:
Pass skinning keys to dialog javascript class so we can skin the dialog.
While it handles blocking clicks to parent, it doesn't handle keeping
keyboard nav inside the iframe.
Your thoughts please...
Danny
--
Chordiant Software Inc.
www.chordiant.com
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Chordiant Software Inc.
www.chordiant.com
Re: Early Prototype - Dialog using DHTML / iFrame
Patch file available here: http://thefoxberry.com/
Only note, is that this also contains the panelPopup component, and that
you'll need to include the two .js files into the servlet that merges the
common javascript. If I get chance later, I'll do this and repost the
patch.
Should work fine in Firefox or IE, others are untested.
Danny
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
I'll post up a .patch file later today.
I used custom .js for the dialog, as I wasn't sure how we'd go about
integrating a 3rd party lib, and the few I looked at didn't quite fit right,
or had license issues. Besides, it was good practice. However, if we have
a library that we're trying to integrate with on a larger scale, then I
think it makes sense.
D.
On 1/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEy Danny,
two things;
1) the image looks great.
2) do you use one of these days upcoming ajax-ish JavaScript libs?
(or custom JS?)
Another one, will you also provide the source in somewhat format?
That would allow us to start with a sandbox ..
Thanks,
Matthias
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hey,
In a timely fashion, I've just seen Adams comments about wanting to
switch
to a DHTML/iFrame solution for dialog windows.
I've pulled together a prototype set of changes that switches the
default
implementation of dialog windows, to use a floating popup iframe. It
seems
to work well and both the date picker dialog and the number picker
demo work
without any alteration. It is implemented as a javascript component
that
inherits from the basic panelPopup component I posted a while
back. The
prototype renders an iframe that blocks access to the parent window
until
the dialog returns.
I say prototype, because I need some feedback on what is/isn't allowed
to
change inside the current dialog framework. Meaning - do we have to
introduce two modes of running, where dialogs will appear in either a
browser window, or in a DHTML iframe? Could we kill off the browser
window
version as there seems to be a very large amount of JavaScript that we
could
tear out if we did.
I'll post a war file this afternoon demonstrating how it works, but
for now
here's a quick picture and the list of changes.
http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg
DialogRequest.java modified to call an alternative javascript method
for
opening the dhtml dialog. When the dialog is launched it is populated
with
the necessary properties for callback when the dialog is closed, thus
no
array of dialogs (var ADFDialogReturn = new Array()) needs to be
maintained.
function _launchPopupDialog(
srcURL,
features,
formName,
postbackId,
partial)
{
_theDialog.callback = _returnFromDialogAndSubmit;
_theDialog.callbackProps = { formNameKey:formName,
postbackKey:postbackId, partialKey:partial };
_theDialog.resize(features['height'], features['width']);
_theDialog.launchDialog(srcURL);
}
On close the dialog will call the following callback function
function _returnFromDialogAndSubmit(props, value) {
if (props)
{
var formName = props['formNameKey'];
var postbackId = props['postbackKey'];
var partial = props['partialKey'];
if (partial)
_submitPartialChange(formName, 0, {rtrn:postbackId});
else
submitForm(formName, 0, {rtrn:postbackId});
}
}
CoreRenderKit.returnFromDialog() - modified to return the following
scriptlet, which closes the dialog and causes the above callback to
occur.
scriptparent.parent.returnFromDialog();/script
Window.js - _sizeWin() function - disabled until I have time to
rework. If
left untouched it resizes the window - which because the dialog is an
iframe
means it resizes the main window.
Minor changes to DateField.js to call my dialog component rather than
openWindow, along with an additional callback function for passing the
selected date back to the parent component.
To Do:
Pass skinning keys to dialog javascript class so we can skin the
dialog.
While it handles blocking clicks to parent, it doesn't handle keeping
keyboard nav inside the iframe.
Your thoughts please...
Danny
--
Chordiant Software Inc.
www.chordiant.com
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Chordiant Software Inc.
www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com
Re: Popup without dialog
I've updated the code and jars for my tr:panelPopup component. You can download the source (just unzip it over your subversion tree) or download the pre-built jars. You can find instructions here http://thefoxberry.com/ Cheers, Danny
Re: What DevEnv do you use for Trinidad
well myeclipse - which now has WTP underneath it - so yes. On 12/15/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: do you use 'WTP ? On 12/15/06, Danny Robinson [EMAIL PROTECTED] wrote: Thanks All, for your responses. I now have a working Eclipse/Trinidad environment. The only things I would add to Scotts notes, are: You need to define a Classpath Variable called M2_REPO, and point that to your maven repository (defaults to something like C:/Documents and Settings/drobinso/.m2/repository). Required if you don't have the maven plugin for eclipse) Changed the 'default output folder' for each project to 'bin', previously set to target/classes, but this caused 'file exists' errors in Eclipse, so now maven and Eclipse build to different locations. Thanks, Danny On 12/14/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I use eclipse with the four projects and it works just fine. I do have a suggestion though: 1. Turn off automatic compile - eclipse has trouble removing the target directories sometimes because the targets are referred to in the project as source. Comes from the automatic generation of the tags. 2. Be sure to do an mvn install before importing the projects. I suggest doing a mvn clean install eclipse:eclipse the first time. This is because some of the files in the Trinidad build are generated and without running the maven task, you don't get these generated files. 3. Either clean and build all the projects, or build them one at a time in the following order: build, api. impl, demo They only real annoying thing is that the demo project shows up as a normal java project rather then a Web Project, so hopefully the mvn eclipse plugin will be enhanced soon to support Calisto. Finally, I havn't used the mvn plugin for eclipse, so I can't speak to that but I hope this helps. Scott Adam Winer wrote: And I use Emacs and a command-line, which I imagine makes me very old-school. ;) -- Adam On 12/14/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Danny, The most common ones I've heard of are either Eclipse or Oracle JDeveloper. I use the latter and create workspace/project files by running the command mvn install jdev:jdev. I believe the expected generated workspace should have 4 projects (api, build, demo, impl) with pre-attached dependencies so you just need to run a jspx page from the demo project and automatically it will build any changes you make in the other projects. Perhaps someone else on this list can better talk to the Eclipse issues you are experiencing. Regards, Matt On 12/14/06, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Are most people using Eclipse to develop the Trinidad components/code? If not, then what do people mainly use? I followed the wiki page that details the Eclipse setup for Trinidad and got a clean compile. However, I'm not certain everything's as it should be, and I certainly can't use the maven eclipse plugin to do a clean 'install'. Using a different approach, 'mvn eclipse:eclipse' command created 4 projects rather than the 2 mentioned in the wiki. However, these wouldn't cleanup compile due to dependencies. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com
What DevEnv do you use for Trinidad
Guys, Are most people using Eclipse to develop the Trinidad components/code? If not, then what do people mainly use? I followed the wiki page that details the Eclipse setup for Trinidad and got a clean compile. However, I'm not certain everything's as it should be, and I certainly can't use the maven eclipse plugin to do a clean 'install'. Using a different approach, 'mvn eclipse:eclipse' command created 4 projects rather than the 2 mentioned in the wiki. However, these wouldn't cleanup compile due to dependencies. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com
Re: Trinidad sandbox?
+1 (non binding). Q1 - Would this add more workload to those with Commit priviledge, or could we open up the commit access a little more for this project? On 12/14/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to add a new sandbox project to trinidad, as a parallel directory to trinidad and plugins. This'd give us a place to add more substantial contributions - Danny Robinson's popup, for example - and give them time to be played around with, fixed up, APIs tweaked, etc., before moving in to the main libraries. It'd also give me a chance for committers like me to add experimental features that definitely shouldn't go into the trunk immediately, or perhaps ever (some ideas I've been toying with for multi-component validation, for example). Feedback? +1 from me. ;) -- Adam -- Chordiant Software Inc. www.chordiant.com
