[Prototype-core] unsubscribe
unsubscribe Carl Zetterberg Tic-Tac Mobile www.tictacmobile.com +46-8-660 66 41 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Deprecated Section.. gone when?
Hi all! Since we are past 1.6.0 final i wonder when you will remove the deprecated portion of the source. Best, Kjell Bublitz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Deprecated Section.. gone when?
On 07/01/2008, Kjell Bublitz [EMAIL PROTECTED] wrote: Hi all! Since we are past 1.6.0 final i wonder when you will remove the deprecated portion of the source. Best, Kjell Bublitz I do this by hand by adding comment tags around the code. That way, it is just an uncomment when you realize you are still relying on some old code! -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Deprecated Section.. gone when?
So it's save to simply delete the section myself if i begin to write a new application using 1.6.x? On Jan 7, 2008 1:42 PM, Richard Quadling [EMAIL PROTECTED] wrote: On 07/01/2008, Kjell Bublitz [EMAIL PROTECTED] wrote: Hi all! Since we are past 1.6.0 final i wonder when you will remove the deprecated portion of the source. Best, Kjell Bublitz I do this by hand by adding comment tags around the code. That way, it is just an uncomment when you realize you are still relying on some old code! -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Deprecated Section.. gone when?
On Jan 7, 2008 1:48 PM, Kjell Bublitz [EMAIL PROTECTED] wrote: So it's save to simply delete the section myself if i begin to write a new application using 1.6.x? Yes. It is also safe to delete the section if you fully port your old scripts to 1.6. Consider that section as a patch that provides parts of the old API on top of the new one. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: element.update( document.createTextNode( hello ) ); [object Text]
element.update(hello) Element.update can take a string (in which case it's set as innerHTML), an Element object, or any object that responds to either toElement or toHTML (and which returns accordingly either an element or a string of html :)) (The same goes for Element.replace and Element.update) Best, -Nicolas On Jan 7, 2008 9:02 AM, kinfei [EMAIL PROTECTED] wrote: using Prototype-version: 1.6.0 Currently element.update( document.createElement( div ) ) ---almost equal--- element.appendChild( document.createElement( div ) ); but it should able do, element.update( document.createTextNode( hello ) ) as element.appendChild( document.createTextNode( hello ) ); --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Development Roadmap
What features are the authors considering in upcoming releases? Or is public discussion of the Prototype/SAU roadmap limited due to factors such as competition with other frameworks? Based on hints dropped in the lists, I can make a few guesses: - Expand Prototype custom events to fire callbacks for Element methods such as update, setStyle, remove, replace, insert, wrap, writeAttribute, addClassName, removeClassName, scrollTo, etc. - Add support for callback registration and multiple callbacks for SAU Effect events - Streamline SAU Effects to all use Effect#Morph - Add Prototype support for onmouseenter and onmouseleave - Add intuitive Prototype methods for checkbox- and radio-group form elements (e.g. a method to get the value of the currently checked item(s) in based on a group name) Can you confirm these and give us some insight? Ken Snyder --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
On Jan 7, 2008 9:25 PM, Ken Snyder [EMAIL PROTECTED] wrote: What features are the authors considering in upcoming releases? Or is public discussion of the Prototype/SAU roadmap limited due to factors such as competition with other frameworks? We don't lay out long roadmaps for Prototype library. Instead, we focus mostly on two future releases: one minor (bug fixes, speedups, minor additions) and one major (major new features, API changes). Some ideas are shared with the community while some are kept private for further discussions among core members. So, the reason we don't share the exact roadmap to Prototype 2.0 with the public is because even we don't know the roadmap yet, and we don't want to set expectations and then break them. - Expand Prototype custom events to fire callbacks for Element methods such as update, setStyle, remove, replace, insert, wrap, writeAttribute, addClassName, removeClassName, scrollTo, etc. That is planned for the next major release. Based on how it performs, it may be pushed further down the road. We'll see. - Add support for callback registration and multiple callbacks for SAU Effect events Is the current model for callbacks in script.aculo.us too limiting? It would be better if you would explain this request with an example. - Add Prototype support for onmouseenter and onmouseleave This is definitely useful to the majority of users. We are still discussing if it's going to become core and in which version. Meanwhile, read the very insightful article by Andrew about why throwing the support for those events out was really a good idea (we had the working implementations far before the 1.6 release): http://andrewdupont.net/2007/11/07/pseudo-custom-events-in-prototype-16/ (The key is revisiting the same problem with another approach, and finally picking the best one) - Add intuitive Prototype methods for checkbox- and radio-group form elements (e.g. a method to get the value of the currently checked item(s) in based on a group name) Hmm, we have it for select boxes and multiple selects, why not radio buttons/checkboxes? You could open up an enhancement ticket for this request and propose an API for this. Or find a way to re-use the existing (get/setValue) API? Thanks for all the questions/suggestions! - Mislav --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Mislav Marohnić wrote: On Jan 7, 2008 9:25 PM, Ken Snyder [EMAIL PROTECTED] Some ideas are shared with the community while some are kept private for further discussions among core members. Why the secrecy? This is an open source project after all. So, the reason we don't share the exact roadmap to Prototype 2.0 with the public is because even we don't know the roadmap yet, and we don't want to set expectations and then break them. Sounds an awful lot like the IE team's arguments about why they are so secretive with IE development. If you want me to invest my projects, my development time and that of my team (if I'm the decision maker) into prototype/SAU then why not give me the information and confidence that I need to make that decision. I understand not wanting to disappoint, but if you're open about the plans as well as the reasons for failure/delay I'm pretty sure the community will forgive you. -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Mislav Marohnić wrote:
...
- Expand Prototype custom events to fire callbacks for Element methods
such as update, setStyle, remove, replace, insert, wrap,
writeAttribute,
addClassName, removeClassName, scrollTo, etc.
That is planned for the next major release. Based on how it performs,
it may be pushed further down the road. We'll see.
Awesome! I've always seen the value for consistently using the wrapper
functions above (i.e. instead of using innerHTML, className, etc.) is
the prospect of callbacks.
- Add support for callback registration and multiple callbacks for SAU
Effect events
Is the current model for callbacks in script.aculo.us
http://script.aculo.us too limiting? It would be better if you would
explain this request with an example.
...
// for example, attach callbacks at any point without having to compose
a new function
var myeffect = Effect.Grow('mydiv', {afterFinish: mycallback1});
//...
myeffect.observe('afterFinish', mycallback2);
// current approach (is this even correct? it is confusing)
var fn = myeffect.options.afterFinish;
myeffect.options.afterFinish = function() {
fn.apply(this, arguments);
mycallback2.apply(this, arguments)
};
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Mislav Marohnić wrote: ... - Add Prototype support for onmouseenter and onmouseleave This is definitely useful to the majority of users. We are still discussing if it's going to become core and in which version. Meanwhile, read the very insightful article by Andrew about why throwing the support for those events out was really a good idea (we had the working implementations far before the 1.6 release): http://andrewdupont.net/2007/11/07/pseudo-custom-events-in-prototype-16/ (The key is revisiting the same problem with another approach, and finally picking the best one) ... I may not completely understand Andrew's argument, but I think the big counter argument is that most other frameworks already support these events. And with 10 lines extra for mouseenter/mouseleave and 20 lines extra for mousewheel, I'm not seeing the slippery slope to bloated code. Furthermore, it seems that browsers are slowly converging on standards compliance (although mouseenter/mouseleave has not been proposed as a standard afaik) which will eventually simplify or remove the extra code for these events. - Ken --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
I periodically share Michael's feelings as well. For me, those concerns would be eliminated if the authors did two things: 1. Publicly disclosed the enhancements they were /considering/ (not necessarily a formal roadmap) 2. Set up a thriving community for official and unofficial plugins For example, I wouldn't mind at all if support for the mouseenter/mouseleave/mousewheel events were released as a tested and endorsed plugin. Then those who were interested could use something they knew would work with current and future versions. I find it unsatisfying that Prototype is used by so many developers worldwide including Rails and many major companies, yet finding good scripts is a Google hit-and-miss affair. I know that months ago the authors created a private built-on-prototype list, but it either died or I got kicked off :) Did that idea get killed? - Pot-Stirrer Ken Michael Peters wrote: Mislav Marohnić wrote: On Jan 7, 2008 9:25 PM, Ken Snyder [EMAIL PROTECTED] Some ideas are shared with the community while some are kept private for further discussions among core members. Why the secrecy? This is an open source project after all. So, the reason we don't share the exact roadmap to Prototype 2.0 with the public is because even we don't know the roadmap yet, and we don't want to set expectations and then break them. Sounds an awful lot like the IE team's arguments about why they are so secretive with IE development. If you want me to invest my projects, my development time and that of my team (if I'm the decision maker) into prototype/SAU then why not give me the information and confidence that I need to make that decision. I understand not wanting to disappoint, but if you're open about the plans as well as the reasons for failure/delay I'm pretty sure the community will forgive you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
This is great. Kudos to Kangax for compiling it! I'm probably dreaming too big, but it would be great if the code was submitted so that it could be hosted on the site and required unit tests to be certified for a certain Prototype version. Plus demos on the site would be fantastic. I really like the ratings system, last modified info and tagging system! - Ken Gareth Evans wrote: Ken, http://scripteka.com/ Prototype extensions library. maintained by Kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Ken, http://scripteka.com/ Prototype extensions library. maintained by Kangax On Jan 8, 2008 10:42 AM, Ken Snyder [EMAIL PROTECTED] wrote: I periodically share Michael's feelings as well. For me, those concerns would be eliminated if the authors did two things: 1. Publicly disclosed the enhancements they were /considering/ (not necessarily a formal roadmap) 2. Set up a thriving community for official and unofficial plugins For example, I wouldn't mind at all if support for the mouseenter/mouseleave/mousewheel events were released as a tested and endorsed plugin. Then those who were interested could use something they knew would work with current and future versions. I find it unsatisfying that Prototype is used by so many developers worldwide including Rails and many major companies, yet finding good scripts is a Google hit-and-miss affair. I know that months ago the authors created a private built-on-prototype list, but it either died or I got kicked off :) Did that idea get killed? - Pot-Stirrer Ken Michael Peters wrote: Mislav Marohnić wrote: On Jan 7, 2008 9:25 PM, Ken Snyder [EMAIL PROTECTED] Some ideas are shared with the community while some are kept private for further discussions among core members. Why the secrecy? This is an open source project after all. So, the reason we don't share the exact roadmap to Prototype 2.0 with the public is because even we don't know the roadmap yet, and we don't want to set expectations and then break them. Sounds an awful lot like the IE team's arguments about why they are so secretive with IE development. If you want me to invest my projects, my development time and that of my team (if I'm the decision maker) into prototype/SAU then why not give me the information and confidence that I need to make that decision. I understand not wanting to disappoint, but if you're open about the plans as well as the reasons for failure/delay I'm pretty sure the community will forgive you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
On Monday 07 January 2008, Ken Snyder wrote: - Expand Prototype custom events to fire callbacks for Element methods such as update, setStyle, remove, replace, insert, wrap, writeAttribute, addClassName, removeClassName, scrollTo, etc. I've written about notifications for DOM changes just today. Have a look: http://schuerig.de/michael/blog/index.php/2008/01/07/dom-change-notification/ Michael -- Michael Schuerig mailto:[EMAIL PROTECTED] http://www.schuerig.de/michael/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Mislav Marohnić wrote: ... - Add intuitive Prototype methods for checkbox- and radio-group form elements ( e.g. a method to get the value of the currently checked item(s) in based on a group name) Hmm, we have it for select boxes and multiple selects, why not radio buttons/checkboxes? You could open up an enhancement ticket for this request and propose an API for this. Or find a way to re-use the existing (get/setValue) API? ... Here is a brainstorm: http://pastie.caboo.se/136408 Is it intuitive, though? I would have expected the whole serializing system to go by name instead of element. I think it is too late to change that because it would break the way some people are currently using $F(). But maybe the brainstorm above is a good approach? - Ken --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
Yup, That's awsome. Very insightful remarks, too. How does the performance feel ? Best, Tobie On Jan 7, 11:26 pm, Michael Schuerig [EMAIL PROTECTED] wrote: On Monday 07 January 2008, Ken Snyder wrote: - Expand Prototype custom events to fire callbacks for Element methods such as update, setStyle, remove, replace, insert, wrap, writeAttribute, addClassName, removeClassName, scrollTo, etc. I've written about notifications for DOM changes just today. Have a look: http://schuerig.de/michael/blog/index.php/2008/01/07/dom-change-notif... Michael -- Michael Schuerig mailto:[EMAIL PROTECTED]://www.schuerig.de/michael/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Development Roadmap
On Jan 8, 9:33 am, Ken Snyder [EMAIL PROTECTED] wrote:
Mislav Marohnić wrote:
...
- Add intuitive Prototype methods for checkbox- and radio-group form
elements ( e.g. a method to get the value of the currently checked
item(s) in based on a group name)
Hmm, we have it for select boxes and multiple selects, why not radio
buttons/checkboxes? You could open up an enhancement ticket for this
request and propose an API for this. Or find a way to re-use the
existing (get/setValue) API?
...
Here is a brainstorm:http://pastie.caboo.se/136408
Is it intuitive, though?
I would have expected the whole serializing system to go by name instead
of element. I think it is too late to change that because it would break
the way some people are currently using $F(). But maybe the brainstorm
above is a good approach?
- Ken
This has annoyed me enough that I'm now using an extension that adds
Form.Field which accesses form elements by name:
http://www.xprime.com.au/prototype_form-field.js
I now use:
* Form.Field.getValue('fieldName')
* Form.Field.setValue('fieldName', value)
* Form.Field.observe('fieldName', 'eventType', listener)
* Form.Field.stopObserving('fieldName', 'eventType', listener)
and don't need to use Form.Element (or $F()) now for most things
because this can be used for both grouped and singular form elements.
A couple of things in there that some might find disturbing though; it
uses the CSS selector to get the elements (could/should do a walk
through elements and match tagName and name attributes instead) and it
has a cache to speed it up which may not be needed if the CSS selector
usage is removed. The cache has to be cleared if the relevant parts of
the DOM is changed (Form.Field.NamedCache.clear()), there is a hook in
there for Ajax calls which may or may not help when changing the DOM
with Ajax.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
