[Proto-Scripty] Re: New API Doc
How's this going? Very much interested in Going back to page-per- method (rather than a long run-on page). Having the side navigation easy to navigate in the page-per-method style like the old documentation is also of paramount importance. For example, if I click on Hash in the sidebar, I should immediately see an easy to read list of all the methods of the Hash class. As it is, they're in a big block, which is hard to scan through, where the vertical (alphabetical) list was quick and relatively painless. Lots of times, I'm just looking to verify the order of parameters, and it was very helpful to be able to find the exact method very quickly so that in almost no time I'm looking at the page reading the order of the methods. Something else that might be handy way further down the road is an easy way to access these pages by-url. For example, if I need to look up a PHP function to very the argument order, it's as easy as typing in http://php.net/function_name_here -- concrete example being stripos (is it haystack first, or needle first? I never can remember) http://php.net/stripos and I'm there immediately. Obviously way down the road, but certainly something to think about. On Oct 9, 3:56 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi, You're not the only one, not by a long chalk. :-) We're working on it. Tobie, Samuel, and Andrew are working hard to improve the structure, navigation, and presentation, and I'm continuing the ongoing quest of copying over, updating, and fleshing- out the content (which is a manual and labor-intensive process). You should see marked improvemenet in the online docs over the course of the next couple of weeks. What happened is that the project switched from having the documentation be a completely separate thing (in a difficult-to-use tool) to having the documentation be part of the source code (a'la Javadoc), using a new tool built for the purpose called PDoc. That way, when someone changes or adds code, they can update the documentation at the same time, and hopefully the two will be kept much more in sync. (The official policy, in fact, is that code patches with documentation impacts that don't include the documentation updates are rejected.) It also simplifies the process of people reporting and offering patches for documentation errors/ omissions. However, the docs got inadequate testing (and weren't complete) when 1.6.1 was released. 1.6.1 *needed* to be released, there was a lot of good, urgently-needed stuff in there (generally, and for IE8 and Chrome). If you want to, you can still get to the old docs (for now) here:http://prototypejs.org/api However, I expect to finish copying/updating/improving the content Real Soon Now (happen to be working on that today), which will at least address the content issue. And Tobie and Samuel just had a week- long codefest on the tool so we should see those improvements very soon. One thing that would be *really* useful would be to know what it is you find difficult about navigation (and just generally what's difficult about using the docs), so that that feedback can, um, feed into the improvement process. Two things that Tobie et. al. are already doing are 1) Going back to page-per-method (rather than a long run-on page), and 2) Adding syntax highlighting to examples I'm sure there are other things they're doing as well, those just happen to be the two I know of. What else needs to be done? Thanks, -- T.J. Crowder Independent Software Consultant tj / crowder software / comwww.crowdersoftware.com On Oct 8, 7:00 pm, louis w louiswa...@gmail.com wrote: It's also just plain hard to navigate and understand all of the different methods available. An example. If I select Event there is no longer the list of available methods appearing in the sidebar menu. Then I need to scroll down a page which is visually hard to scan to be able to pick out 'isRightClick' in light grey text buried in a sea of bright blue boxes. Usability should be a key factor when redesigning a documentation system. The amount of times a developer will be using this site is high. They should be able to pop in, find what they want quickly and leave. Not get lost poking around the site. I sure hope this is all to do with it's infancy. On Oct 8, 1:26 pm, DJ Mangus d.man...@gmail.com wrote: No. You aren't. Sent from my phone so pardon the spelling errors. On Oct 8, 2009, at 10:22 AM, louis w louiswa...@gmail.com wrote: Am I the only one that missed the old onlineapidocs? This new one seems hard to use. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For
[Proto-Scripty] Ajax.Request with JSON response
I'm trying to do something that is probably very basic for most.
I'm trying to send an Ajax.Request while validating a form. I'd like
a JSON response like this:
{success: true, htmlCode: blah, blah, blah}
Help is always greatly appreciated.
Attempt
1
This sends back the right response, but I can't parse it so that I
know it was successful and then use the htmlCode. It just updates the
div tag with the entire JSON response.
function ajaxRequest(){
var url = /cgidev2p/r_chgpwd.pgm;
var pars = 'v_current=' + escape($F('v_current')) +
'v_new=' + escape($F('v_new')) + 'v_confirm=' + escape($F
('v_confirm')) + 'sessionid=' + escape($F('sessionid'));
var target = 'v_messege';
var ajaxObjhttp = new Ajax.Request(url, {
method: 'post',
parameters: pars,
onCreate: function(transport){
var myAjax = new Ajax.Updater(target, url, {
method: 'get',
parameters: pars
});
//alert(Creating New Ajax Call);
},
onSuccess: function(transport){
var json = transport.responseText.evalJSON();
var submitObj = document.getElementById
('goButton');
if (json.success) {
submitObj.disabled = false;
document.getElementById('goButton').focus;
}
else {
submitObj.disabled = true;
}
}
});
}
Attempt
2
I think this is more what I need. It makes the request, but again I
don't know how to handle the json coming back so that I know if it was
successful and then use the second parm.
function ajaxRequest2(){
var url = /cgidev2p/r_chgpwd.pgm;
var pars = 'v_current=' + escape($F('v_current')) +
'v_new=' + escape($F('v_new')) + 'v_confirm=' + escape($F
('v_confirm')) + 'sessionid=' + escape($F('sessionid'));
new Ajax.Request(url, {
method: 'get',
parameters: pars,
onSuccess: function(transport){
var json = transport.responseText.evalJSON
(true);
// v_messege.update(json).setStyle
({ background: '#dfd' });
alert(json);
}
});
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Anomaly in IE8 or am I assuming too much from $('formName').serialize(true)?
Hi,
Doesn't serialize() just work with Element.id?
No, the `name` and `id` attributes have completely different
purposes. A form field must have a `name` attribute to be sent as
part of the form (this is an HTML thing, not a Prototype thing). The
`id` attribute is unrelated to forms, it's used for addressing
elements (looking them up in JavaScript or using them as anchors).
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Oct 27, 9:07 pm, bernard bernard.christophe...@gmail.com wrote:
I have a form whose elements (input, select) were given explicit IDs, but no
name.
when I do this:
var parmHash;
parmHash = $('myForm').serialize(true)
parmHash is empty. When i gave the form elements name='someName',
parmHash is completed as expected. Doesn't serialize() just work with
Element.id?
Ozy: Life is full of disappointments.
Millie: No it isn't. I can always fit more in.
[D.C. Simpson]
A little trust goes a long way. The less you use,
the farther you'll go.
[Howard Tayler]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: New API Doc
Something else that might be handy way further down the road is an easy way to access these pages by-url. For example, if I need to look up a PHP function to very the argument order, it's as easy as typing inhttp://php.net/function_name_here-- A big +1 for that, I really like that about the old docs. -- T.J. On Oct 27, 11:29 pm, Adm.Wiggin admwig...@gmail.com wrote: How's this going? Very much interested in Going back to page-per- method (rather than a long run-on page). Having the side navigation easy to navigate in the page-per-method style like the old documentation is also of paramount importance. For example, if I click on Hash in the sidebar, I should immediately see an easy to read list of all the methods of the Hash class. As it is, they're in a big block, which is hard to scan through, where the vertical (alphabetical) list was quick and relatively painless. Lots of times, I'm just looking to verify the order of parameters, and it was very helpful to be able to find the exact method very quickly so that in almost no time I'm looking at the page reading the order of the methods. Something else that might be handy way further down the road is an easy way to access these pages by-url. For example, if I need to look up a PHP function to very the argument order, it's as easy as typing inhttp://php.net/function_name_here-- concrete example being stripos (is it haystack first, or needle first? I never can remember)http://php.net/striposand I'm there immediately. Obviously way down the road, but certainly something to think about. On Oct 9, 3:56 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi, You're not the only one, not by a long chalk. :-) We're working on it. Tobie, Samuel, and Andrew are working hard to improve the structure, navigation, and presentation, and I'm continuing the ongoing quest of copying over, updating, and fleshing- out the content (which is a manual and labor-intensive process). You should see marked improvemenet in the online docs over the course of the next couple of weeks. What happened is that the project switched from having the documentation be a completely separate thing (in a difficult-to-use tool) to having the documentation be part of the source code (a'la Javadoc), using a new tool built for the purpose called PDoc. That way, when someone changes or adds code, they can update the documentation at the same time, and hopefully the two will be kept much more in sync. (The official policy, in fact, is that code patches with documentation impacts that don't include the documentation updates are rejected.) It also simplifies the process of people reporting and offering patches for documentation errors/ omissions. However, the docs got inadequate testing (and weren't complete) when 1.6.1 was released. 1.6.1 *needed* to be released, there was a lot of good, urgently-needed stuff in there (generally, and for IE8 and Chrome). If you want to, you can still get to the old docs (for now) here:http://prototypejs.org/api However, I expect to finish copying/updating/improving the content Real Soon Now (happen to be working on that today), which will at least address the content issue. And Tobie and Samuel just had a week- long codefest on the tool so we should see those improvements very soon. One thing that would be *really* useful would be to know what it is you find difficult about navigation (and just generally what's difficult about using the docs), so that that feedback can, um, feed into the improvement process. Two things that Tobie et. al. are already doing are 1) Going back to page-per-method (rather than a long run-on page), and 2) Adding syntax highlighting to examples I'm sure there are other things they're doing as well, those just happen to be the two I know of. What else needs to be done? Thanks, -- T.J. Crowder Independent Software Consultant tj / crowder software / comwww.crowdersoftware.com On Oct 8, 7:00 pm, louis w louiswa...@gmail.com wrote: It's also just plain hard to navigate and understand all of the different methods available. An example. If I select Event there is no longer the list of available methods appearing in the sidebar menu. Then I need to scroll down a page which is visually hard to scan to be able to pick out 'isRightClick' in light grey text buried in a sea of bright blue boxes. Usability should be a key factor when redesigning a documentation system. The amount of times a developer will be using this site is high. They should be able to pop in, find what they want quickly and leave. Not get lost poking around the site. I sure hope this is all to do with it's infancy. On Oct 8, 1:26 pm, DJ Mangus d.man...@gmail.com wrote: No. You aren't. Sent from my phone so pardon the spelling errors. On Oct 8, 2009, at 10:22 AM, louis w
[Proto-Scripty] Re: Ajax.Request with JSON response
Found some examples on this site and tried to simplify it.
var pars = 'v_current=' +
escape($F('v_current')) + 'v_new=' +
escape($F('v_new')) + 'v_confirm=' + escape($F('v_confirm')) +
'sessionid=' + escape($F('sessionid'));
new Ajax.Request(url, {
method: 'get',
parameters: pars,
onSuccess: function(response){
var json =
response.responseJSON;
if (!json) {
alert('alert 1');
}
else {
// Good, got JSON data
alert('alert 2');
if (json.success) {
// Your
server-side code says all went well;
// you'd
probably show json.message, e.g.:
alert('alert
3');
v_messege.update(json.message).setStyle({
background: '#dfd'
});
}
else {
// Your server-side
code ran correctly, but
// returned an error;
handle that.
alert('alert
4');
}
}
}
});
}
My json is either ... {success : true, message : good}
or {success : false, message : bad}
I never get passed alert 1.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Anomaly in IE8 or am I assuming too much from $('formName').serialize(true)?
right-o. merci.
- Original Message -
From: T.J. Crowder
To: Prototype script.aculo.us
Sent: Wednesday, October 28, 2009 1:43 AM
Subject: [Proto-Scripty] Re: Anomaly in IE8 or am I assuming too much from
$('formName').serialize(true)?
Hi,
Doesn't serialize() just work with Element.id?
No, the `name` and `id` attributes have completely different
purposes. A form field must have a `name` attribute to be sent as
part of the form (this is an HTML thing, not a Prototype thing). The
`id` attribute is unrelated to forms, it's used for addressing
elements (looking them up in JavaScript or using them as anchors).
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Oct 27, 9:07 pm, bernard bernard.christophe...@gmail.com wrote:
I have a form whose elements (input, select) were given explicit IDs, but
no name.
when I do this:
var parmHash;
parmHash = $('myForm').serialize(true)
parmHash is empty. When i gave the form elements name='someName',
parmHash is completed as expected. Doesn't serialize() just work with
Element.id?
Ozy: Life is full of disappointments.
Millie: No it isn't. I can always fit more in.
[D.C. Simpson]
A little trust goes a long way. The less you use,
the farther you'll go.
[Howard Tayler]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] DragDrop performances
Hi all, I'm experiencing a performance problem with drag and drop. I drag an image on an html table. I have only one draggable element (the image) and the problem is that until the table is not big in size (let's say 7 columns and 30 rows) the drag effect is very smooth, but when the size of the table is bigger the performance of the drag operation is very rough. I'm testing it in IE8. Any idea is welcome. Thanks in advance, Mattia --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: DragDrop performances
On 28 Oct 2009, at 14:36, MattiaLocatelli wrote: I'm experiencing a performance problem with drag and drop. I drag an image on an html table. I have only one draggable element (the image) and the problem is that until the table is not big in size (let's say 7 columns and 30 rows) the drag effect is very smooth, but when the size of the table is bigger the performance of the drag operation is very rough. I'm testing it in IE8. Any idea is welcome. You're quite vague, but I'm suspecting you have a droppable on every table cell. What you'll need to do, is make the table itself a droppable (only one) and the use the drop coordinates to find out on what cell the draggable was dropped. Best regards Peter De Berdt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: DragDrop performances
Hi,
I don't have any droppable on the table or anywhere in the page. There is
just one draggable element and no droppables. Like in the online sample.
The code to create the draggable element is this :
var draggable = new Draggable(objId, { scroll: window });
Well, I think I found something:
I develop with IE8 and when I use the compatibility mode for IE7 the drag
drop work pretty well. But if I use the IE8 engine is really bad.
Maybe is a problem with the IE8 engine...
2009/10/28 Peter De Berdt peter.de.be...@pandora.be
On 28 Oct 2009, at 14:36, MattiaLocatelli wrote:
I'm experiencing a performance problem with drag and drop.
I drag an image on an html table.
I have only one draggable element (the image) and the problem is that
until the table is not big in size (let's say 7 columns and 30 rows)
the drag effect is very smooth, but when the size of the table is
bigger the performance of the drag operation is very rough.
I'm testing it in IE8.
Any idea is welcome.
You're quite vague, but I'm suspecting you have a droppable on every table
cell. What you'll need to do, is make the table itself a droppable (only
one) and the use the drop coordinates to find out on what cell the draggable
was dropped.
Best regards
Peter De Berdt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: DragDrop performances
Hi all,
I look with the IE8 profiler and I see the updateDrag function in IE8 takes
in my page 456ms and in the IE7 compatibility mode 15 ms.
I think there is soem problems with the recursive execution of this
function.
Thanks,
Mattia
2009/10/28 Mattia Locatelli mattia.locatelli...@gmail.com
Hi,
I don't have any droppable on the table or anywhere in the page. There is
just one draggable element and no droppables. Like in the online sample.
The code to create the draggable element is this :
var draggable = new Draggable(objId, { scroll: window });
Well, I think I found something:
I develop with IE8 and when I use the compatibility mode for IE7 the drag
drop work pretty well. But if I use the IE8 engine is really bad.
Maybe is a problem with the IE8 engine...
2009/10/28 Peter De Berdt peter.de.be...@pandora.be
On 28 Oct 2009, at 14:36, MattiaLocatelli wrote:
I'm experiencing a performance problem with drag and drop.
I drag an image on an html table.
I have only one draggable element (the image) and the problem is that
until the table is not big in size (let's say 7 columns and 30 rows)
the drag effect is very smooth, but when the size of the table is
bigger the performance of the drag operation is very rough.
I'm testing it in IE8.
Any idea is welcome.
You're quite vague, but I'm suspecting you have a droppable on every table
cell. What you'll need to do, is make the table itself a droppable (only
one) and the use the drop coordinates to find out on what cell the draggable
was dropped.
Best regards
Peter De Berdt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: onChange in Dynamic Element not working in IE6
Thank you both for your responses. I have found a workaround for my
problem. This really drove me crazy though the solution is not that
complicated. I’m going to be somewhat long winded so others do not
have to go through this.
I know that calling events from within html is discouraged, my story
is probably another reason not to do this.
First of all, onchange and onbur do not not work as attributes in IE6
for create elements.
For example:
var newSecurityInput = new Element('input',
{'type':'text','class':'text newid', 'name':'newid', 'onChange':
validateNewSecurityChange(this); ,'onBlur': getSecurityName
(this);});
I ended up taking a similar approach as you did for adding class
attributes, I added it after the creation of the element.
var newSecurityInput = new Element('input', {'type':'text',
'class':'text newid', 'name':'newid'});
Event.observe(newSecurityInput,'change',validateNewSecurityChange);
Event.observe(newSecurityInput,'blur',getSecurityName);
My problem was compounded because I had inline html that already
called this function, and passed ‘this’ to it
td class=text
input type=text id=newid1 class=text name=newid1
onChange=validateNewSecurityChange (this);
onBlur=getSecurityName(this); /
The function looked like this
function getSecurityName (obj) {
var securityId = $F(obj);
This had been working fine.
I created a new function for the new create element event that looks
like this.
function getSecurityName() {
var securityId = $F(this);
This did not work as both call went to the same function.
What I had to do was create a function with a different name for the
inline html
function getSecurityNameNoBind(obj) {
var securityId = $F(obj);
td class=text
input type=text id=newid1 class=text name=newid1
onChange=validateNewSecurityChangeNoBind (this);
onBlur=getSecurityName(this); /
I’m still a little confused over why I had to do this but it works.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: New API Doc
A good example of badness in the new API is the page for the Array class. http://api.prototypejs.org/language/array.html Big block of text that's probably useful, but I want a list of methods that's quick and easy, and always one of the first things I see. On Oct 27, 5:29 pm, Adm.Wiggin admwig...@gmail.com wrote: How's this going? Very much interested in Going back to page-per- method (rather than a long run-on page). Having the side navigation easy to navigate in the page-per-method style like the old documentation is also of paramount importance. For example, if I click on Hash in the sidebar, I should immediately see an easy to read list of all the methods of the Hash class. As it is, they're in a big block, which is hard to scan through, where the vertical (alphabetical) list was quick and relatively painless. Lots of times, I'm just looking to verify the order of parameters, and it was very helpful to be able to find the exact method very quickly so that in almost no time I'm looking at the page reading the order of the methods. Something else that might be handy way further down the road is an easy way to access these pages by-url. For example, if I need to look up a PHP function to very the argument order, it's as easy as typing inhttp://php.net/function_name_here-- concrete example being stripos (is it haystack first, or needle first? I never can remember)http://php.net/striposand I'm there immediately. Obviously way down the road, but certainly something to think about. On Oct 9, 3:56 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi, You're not the only one, not by a long chalk. :-) We're working on it. Tobie, Samuel, and Andrew are working hard to improve the structure, navigation, and presentation, and I'm continuing the ongoing quest of copying over, updating, and fleshing- out the content (which is a manual and labor-intensive process). You should see marked improvemenet in the online docs over the course of the next couple of weeks. What happened is that the project switched from having the documentation be a completely separate thing (in a difficult-to-use tool) to having the documentation be part of the source code (a'la Javadoc), using a new tool built for the purpose called PDoc. That way, when someone changes or adds code, they can update the documentation at the same time, and hopefully the two will be kept much more in sync. (The official policy, in fact, is that code patches with documentation impacts that don't include the documentation updates are rejected.) It also simplifies the process of people reporting and offering patches for documentation errors/ omissions. However, the docs got inadequate testing (and weren't complete) when 1.6.1 was released. 1.6.1 *needed* to be released, there was a lot of good, urgently-needed stuff in there (generally, and for IE8 and Chrome). If you want to, you can still get to the old docs (for now) here:http://prototypejs.org/api However, I expect to finish copying/updating/improving the content Real Soon Now (happen to be working on that today), which will at least address the content issue. And Tobie and Samuel just had a week- long codefest on the tool so we should see those improvements very soon. One thing that would be *really* useful would be to know what it is you find difficult about navigation (and just generally what's difficult about using the docs), so that that feedback can, um, feed into the improvement process. Two things that Tobie et. al. are already doing are 1) Going back to page-per-method (rather than a long run-on page), and 2) Adding syntax highlighting to examples I'm sure there are other things they're doing as well, those just happen to be the two I know of. What else needs to be done? Thanks, -- T.J. Crowder Independent Software Consultant tj / crowder software / comwww.crowdersoftware.com On Oct 8, 7:00 pm, louis w louiswa...@gmail.com wrote: It's also just plain hard to navigate and understand all of the different methods available. An example. If I select Event there is no longer the list of available methods appearing in the sidebar menu. Then I need to scroll down a page which is visually hard to scan to be able to pick out 'isRightClick' in light grey text buried in a sea of bright blue boxes. Usability should be a key factor when redesigning a documentation system. The amount of times a developer will be using this site is high. They should be able to pop in, find what they want quickly and leave. Not get lost poking around the site. I sure hope this is all to do with it's infancy. On Oct 8, 1:26 pm, DJ Mangus d.man...@gmail.com wrote: No. You aren't. Sent from my phone so pardon the spelling errors. On Oct 8, 2009, at 10:22 AM, louis w louiswa...@gmail.com wrote: Am I the only one that missed the old
[Proto-Scripty] Works in FF3 not IE8
function ajaxRequest2(){
var url = /cgidev2p/r_chgpwd.pgm;
var pars = 'v_current=' +
escape($F('v_current')) + 'v_new=' +
escape($F('v_new')) + 'v_confirm=' + escape($F('v_confirm')) +
'sessionid=' + escape($F('sessionid'));
var submitObj =
document.getElementById('goButton');
new Ajax.Request(url, {
method: 'get',
parameters: pars,
onSuccess: function(transport){
var message = $('message');
if (!transport.responseText) {
//alert('alert 1');
}
else {
if
(transport.responseText == 'You may submit your change.') {
v_messege.update(transport.responseText).setStyle({
background: '#dfd'
});
submitObj.disabled = false;
}
else {
v_messege.update(transport.responseText).setStyle({
background: '#fdd'
});
submitObj.disabled = true;
}
}
}
});
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
