No I'm not a JavaScript expert but, with all due respect, it doesn't
seem like there are any JavaScript gurus here anyway.
I'm sorry? You are addressing probably one of the largest gathering of
JavaScript gurus on the planet.
If you don't like prototype.js or script.aculo.us, don't use it. Post
On 7/11/06, Todd Ross <[EMAIL PROTECTED]> wrote:
Why? Without testing it, I'd speculate that when the is
shown, its height would be 0 (or near-0 depending on styles applied)
because the inner div would be set display:none and have no place in
the page flow. The animation would then gradually
On 7/11/06, Eskil Kvalnes <[EMAIL PROTECTED]> wrote:
On 7/10/06, Bauser, Joseph (Joe) <[EMAIL PROTECTED]> wrote:
>
>
>
> If I remember correctly, you can't use that effect on tables. But I may be
mistaken.
You seem to be right... no available workaround to this or a somewhat
similar
function
I think $$ could very well be fast enough for what you want to do.
Never trade off performance against developer productivity unless you
have a very good reason to do it.
On 7/3/06, Andrew Kaspick <[EMAIL PROTECTED]> wrote:
I would have to think that $('abc').getElementsByTagName('span') would
r
Just to let you know. The demo doesn't work in Safari because the
"drag an image" built-in drag-drop behaviour kicks in instead of your
JavaScript drag-handler. Not sure how to fix it but doing an
Event.stop might do it...
Other than that, really cool stuff!
Cheers,
Jon
On 4/24/06, Michael Dain
It's not in the docs as it's not really part of the API. It converts
's to line breaks before it displays the textarea. It does not
convert back again as this is the responsibility of the server. This
seems to be the desired behaviour a lot of times, but not always.
Hence it should be configurable.
Yes, that should obviously be configurable. Submit a patch and I'm
sure you'll get it committed.
On 3/28/06, Jamie Orchard-Hays <[EMAIL PROTECTED]> wrote:
> I'm curious if anyone else has a need to disable
> *convertHTMLLineBreaks*. I actually need to show the 's and 's
> in the editor and browsin
/06, Jamie Orchard-Hays <[EMAIL PROTECTED]> wrote:
> Thanks for that tip Jon. I hadn't noticed that one. So ajaxOptions is
> standard in the framework?
>
> btw, Nicolas's solution also worked.
>
> Jamie
> On Jan 30, 2006, at 2:57 PM, Jon Tirsen wrote:
>
> >
I think you should be able to use the ajaxOptions option just like you
would any other option for an Ajax.Request. IIRC ajaxOptions:
{onSuccess: function() {...blah...}} should do the trick.
HTH
Cheers,
Jon
On 1/26/06, Jamie Orchard-Hays <[EMAIL PROTECTED]> wrote:
> I'm looking for onSuccess: in
On 1/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > That's just the nature of HTML. Yes, you would need
> > to replace the EOL with a on the server.
> I'm working with PHP and try to use nl2br function. The result isn't
> correct, but you have confirm to me that this is the right way.
> No
On 1/6/06, Gregory Hill <[EMAIL PROTECTED]> wrote:
> > Most proxy servers don't support gzip-compressed so corporate users
> > still aren't going to benefit from mod_gzip.
>
> We have a squid proxy here at work and it seems to be accepting the
> pages just fine. Or at least all the headers are the
On 1/6/06, Gregory Hill <[EMAIL PROTECTED]> wrote:
> Yeah, but if they're using a proxy, they should be caching the pages anyway,
> right?
Not necessarily. The main reason corporate users use a proxy is that
they don't want to give direct outbound access to the internet to
clients. So the firewall
ink I can try to replace the eol with a BR
>
> Thank you,
> Antonello
>
>
>
> >
> > On 1/6/06, Jon Tirsen <[EMAIL PROTECTED]> wrote:
> >> That sounds odd. Could you give us a dump of the request content as it
> >> comes back, please?
> >>
Btw, does it work if you don't use method: 'get' (and use the default
'post') instead?
On 1/6/06, Jon Tirsen <[EMAIL PROTECTED]> wrote:
> That sounds odd. Could you give us a dump of the request content as it
> comes back, please?
>
> On 1/6/06, [EMAIL P
That sounds odd. Could you give us a dump of the request content as it
comes back, please?
On 1/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi to all.
>
> First of all exchuse for my bad english
>
> I try to use Ajax.InPlaceEditor with a textarea:
> ##
> new Ajax.InPlaceEd
Most proxy servers don't support gzip-compressed so corporate users
still aren't going to benefit from mod_gzip.
:-(
On 1/6/06, Gregory Hill <[EMAIL PROTECTED]> wrote:
>
>
>
> I just use mod_gzip on my apache server and all my pages get compressed to a
> fraction of their size automatically. Hav
Sorry, the function takes two arguments, first the form and then the
actual value of the field so it needs to look like this:
function(form, value) { return 'name=' + value;}
Is there any documentation out there with the incorrect form of the
function that I need to update?
On 11/30/05, Brandon D
Agreed. I think it makes sense to integrate a rich text editor with
Scriptaculous and make sure it works seamlessly together. If someone
ends up doing this they could donate this integration back to
Scriptaculous.
On 11/28/05, Maninder, Singh <[EMAIL PROTECTED]> wrote:
> Thanks Casey. Yes, I know
The loadTextURL only gets evaluated once, when the control is created.
This is just how JavaScript works. To change the loadTextURL you need
to explicitly change it every time you change the currentPage, like
this:
inPlaceEditor.options.loadTextURL = "getPage.php?page=" + currentPage;
On 11/24/05
I don't think "value" is a keyword in JavaScript.
On 11/22/05, Brandon Dove <[EMAIL PROTECTED]> wrote:
> "value" is the name of the attribute created in the temporary
> form used for the in place editing. I would assume that if this
> was really the problem that almost everyone using this would be
hopefully
> be integrated into scriptaculous itself... seems like there are
> various projects going on and they're going to be easy to lose track
> of for the rest of us.
>
> Could that go into the scriptaculous wiki itself?
>
> On 11/21/05, Jon Tirsen <[EMAIL PROTECTED]>
I've written an "Expando" component. A simple component that you can
expand and collapse and loads it content using Ajax. Using that it
should be relatively simple to build a tree component.
Is this something you want? Shall I submit it?
On 11/21/05, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> That
The method is called "dispose":
var ipe = {};
ipe["menuItem1"] = new Ajax.InPlaceEditor( 'name, 'link', {} );
ipe["menuItem1"].dispose();
On 11/21/05, Jono Young <[EMAIL PROTECTED]> wrote:
> Howdy,
>
> I have created several InPlaceEditor's for each of my menu items. This way i
> can easily renam
I patched my Rico to handle it, seems to work fine.
The problem is the Object.prototype.extend which has been replaced by
Object.extend (instance method is now a class method). Can't remember
the line number but it's in the _setOptions method.
That said, it would be nice if we could just implemen
In Rails the best way is probably to use the URL itself rather than a
parameter. Like this:
new Ajax.InPlaceEditor('title-<%= book.id -%>',
<%= url_for :action => 'update_book_title', :id => book.id %>);
I don't think the error you're getting is related to the InPlaceEditor
at all.
x = [1,2,3];
x.each(function (i) {
document.write(i);
});
On 11/4/05, Martin Scheffler <[EMAIL PROTECTED]> wrote:
>
> Hi all, when I want to interate through an array, all those pesky Prototype
> functions get in my way!
>
> When I do this:
> -
>
> r="";
> for(x in new Array
> HTML Transitional allows inputs in FORMs, but HTML Strict does not:
>
> Contents
> * In HTML 4.0 Strict, one or more SCRIPT or block-level elements except FORM
> * In HTML 4.0 Transitional, inline elements or block-level elements
> except FORM
> http://htmlhelp.com/reference/html40/forms/form
This is not currently supported in the InPlaceEditor although it is
definitely possible to support. Either have a stab at it yourself or
create an issue for it in the issue tracker
http://dev.rubyonrails.com. This sounds fun so I might have a look at
it later myself. (Unfortunately no guarantees on
So that means the InPlaceEditor is producing valid XHTML right?
On 11/1/05, Niels Leenheer <[EMAIL PROTECTED]> wrote:
> On 10/28/05, Jay Levitt <[EMAIL PROTECTED]> wrote:
> > Jon Tirsen wrote:
> > The INPUT field is in a FORM field. Isn't it valid to have
The INPUT field is in a FORM field. Isn't it valid to have an INPUT
field in a FORM tag?
Cheers,
Jon
On 10/28/05, Jay Levitt <[EMAIL PROTECTED]> wrote:
> It's not a critical bug by any means, but shouldn't InPlaceEditor put
> DIV tags around the INPUT field? From what I can tell on the W3C
> val
> Really? The use case might not be common but it seems like it should
> be easy to design the code so it's supportable. I assume after the
> user types something in you'll have that in a variable then execute
> the Ajax stuff. Wouldn't it be simple to just short circuit the ajax
> call and return
This should be possible to do with some heavy hacking of the
InPlaceEditor. Essentially just strip out the Ajax calls from it and
instead save the new value in a field.
This is a pretty special requirement so I don't think we'll at this
stage try to support it in the standard implementation.
On 1
Wow! Yeah, it crashes 1.0.6 on Mac too. I'll look into it.
On 10/27/05, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> The patch has been applied.
>
> Btw, the unit test now crashes Firefox 1.0.4, I can consistenly
> reproduce this here.
>
> Cheers,
> Thomas
>
&
You're html got defanged, you should probably send as zip.
___
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
out?
> Im thinking that since it works if an alert is shown before, maybe
> all it needs
> is time to set everything right in the DOM. A setTimeout might do the
> trick!
>
> -Michael
>
>
> Den 26/10/2005 kl. 22.56 skrev Jon Tirsen:
>
> > Removing the Field.focus doe
Ok, browser conditional logic applied, this patch fixes it in Safari
and Firefox:
http://dev.rubyonrails.com/ticket/2616
Dunno 'bout IE, but nobody uses IE these days do they!? ;-)
On 10/27/05, Jon Tirsen <[EMAIL PROTECTED]> wrote:
> Hahaha, this is great! If I use Field.sel
n 10/27/05, Jon Tirsen <[EMAIL PROTECTED]> wrote:
> Removing the Field.focus does indeed solve the scrolling issue. That
> does seem to be a bug, I mean if you focus a field you don't want to
> scroll to the top do you? How shall we work around this? Conditionally
> not do the
Removing the Field.focus does indeed solve the scrolling issue. That
does seem to be a bug, I mean if you focus a field you don't want to
scroll to the top do you? How shall we work around this? Conditionally
not do the focus if we're on Firefox? Isn't that really ugly? Ideas?
On 10/27/05, Jay Lev
Unfortunately this fix doesn't seem to work at all. :-( The code was
already stopping the event and even when I return false from the
function it still scrolls to the top. We're back to square one.
:-(
Cheers,
Jon
On 10/26/05, Jon Tirsen <[EMAIL PROTECTED]> wrote:
> On 10/26
On 10/26/05, Rahul Bhargava <[EMAIL PROTECTED]> wrote:
>
> 1) have an argument so that the event can be passed into the method (this is
> what bindAsEventListener lets you do)
>
> enterEditMode: function(evt) {
You're correct, but sometimes enterEditMode is called without the
event argument (fro
> I think that usually means that the href points to "#" and one of two things:
>
> 1) the onclick event handler is not returning false to cancel out the
> actual link action
> 2) the onclick event handler is erroring out
>
> I haven't looked at the IPE much, however.
The thing is, it's not a anch
Yeah, you're right! That's really annoying! Can anyone figure out why
it does this?
On 10/25/05, Jay Levitt <[EMAIL PROTECTED]> wrote:
> When I click an InPlaceEditor field in Firefox 1.0.7, the page scrolls
> up to the top. That's disconcerting, and often ends up with the
> editable field out of
42 matches
Mail list logo
