[mochikit] Re: DOM Manipulation: Setting textNode to html string.
On Nov 1, 2006, at 8:02 AM, abargnesi wrote: Zac, Thanks for the tip. I used innerHTML on the TD after I created it and it works perfectly (at least in firefox). The reason why I used Mochikit is because I would like to not use innerHTML (not standard) and also avoid performance penalties by using the DOM Api directly. Is there a way of doing this besides innerHTML or creating the element directly? Nope. If you're unwilling to use innerHTML (or are just concerned with a non-pure-DOM approach), your only real option is not using serialized (X)HTML. Use JSON structures and build the DOM programmatically. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Mochikit.Visual
On Nov 1, 2006, at 2:21 PM, Dave Woodwater wrote: Hi, I'm trying out Mochikit to see if it's the right tool for the job. I can pretty much get everything I need a'working, but for some reason I keep getting errors when trying to call the visuals. I get toggle/puff/etc... not defined. I included the js in the page and I'm trying to figure out what I did wrong. Can anyone help me on this. Did you include New.js? It's necessary for most of the Visual stuff, at least until 1.4 is cooked. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Back Button
On Sep 18, 2006, at 5:38 AM, m_waschkowski wrote: Well, it seems to me that concept of 'Back Button Support' is pretty straightforward - you press the back button, and then go to the last visited page. ie. just what people expect the back button to do. I did see some javascript type solutions, but whatever solution that I can implement that would allow me to simply recreate the function of the back button when doing AJAX stuff is what I'm looking for, and what I was able to dig up didn't look simple... The back button concept goes out the window once you start introducing smaller, asynchronous, sub-page requests. Most solutions I've seen involve modifying the window.location attribute (usually changing hash values), but these solutions are more often for AJAXy navigation than any real undo. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: toDOM(html) as counterpart to toHTML(dom)
On Sep 12, 2006, at 8:50 AM, Marc Boeren wrote:
Hi,
Is it useful to have a simple toDOM(html) function in MochKit.DOM? I
like it because I can make simple templates as html snippets, which I
find more readable than the corresponding createDOM constructions.
Usage:
var html = 'div class=selectionimg src=example.png/My
Text/div';
var domElements = toDOM(html);
var container= getElement('container');
for(i=0, n=domElements.length; in; ++i) {
container.appendChild(domElements[i]);
}
The implementation is simple (as standalone function):
function toDOM(html)
{
var div = MochiKit.DOM.DIV();
div.innerHTML = html;
return div.childNodes;
}
Does anyone know how wel-supported the non-standard innerHTML is?
If you're using it for the implementation, why not just short circuit
it all with:
var container = getElement('container');
container.innerHTML = html;
?
Zac
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~--~~~~--~~--~--~---
[mochikit] Re: Bug in MochiKit.DOM ???
On Aug 29, 2006, at 5:35 PM, Beau Hartshorne wrote:
On 29-Aug-06, at 2:07 PM, Zachery Bir wrote:
I just figured it out. One must use the camel case notation for the
CSS
attribute lists. It would perhaps help to mention that in the
doco. :p
You're in Javascript, not CSS. Put it in a .css file, or use
Javascript notation for style declarations.
I don't think it's necessarily clear that you should use camelCase
there. mirage, what should the docs say? Could you open a ticket
with your suggested clarification? Just an example using {'style':
{'backgroundColor': 'red'}} might be enough.
Maybe, *shrug*, every Javascript reference I've seen points out that
css style attributes need to be camel cased. Just because they're in
quotes here doesn't strike me as obviating that. It's still in
Javascript source. :^)
Zac
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~--~~~~--~~--~--~---
[mochikit] Re: Bug in MochiKit.DOM ???
On Aug 29, 2006, at 5:02 PM, mirage wrote: Gaaahh!!! I just figured it out. One must use the camel case notation for the CSS attribute lists. It would perhaps help to mention that in the doco. :p Gaaahh!!! You're in Javascript, not CSS. Put it in a .css file, or use Javascript notation for style declarations. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: search for children
On Aug 3, 2006, at 10:12 AM, elio wrote: Hi group, a simple question: this doen't work: $(node).getElementsByTagAndClassName(UL); what do you use to look for tags inside an element? It's not a method, it's a function: getElementsByTagAndClassName(UL, null, node) You'll need to pass in null for the class name argument. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Event propagation question
On Jul 18, 2006, at 11:11 PM, Chris Nokleberg wrote: I have some mousedown events that are mostly handled by a floating component but for reasons specific to my UI the parents still need to see the event--that is, I cannot use stopPropagation. However, the parent needs to know that some action has already been taken. I tried setting a JS property on the event but that didn't work--apparently the Signal module creates a new wrapper for each listener. My workaround was to get the native event and set a property on it instead. Perhaps this isn't a MochiKit question per se but the docs do say that the native event should never be needed so I thought I'd ask if there is a better way. Why not have the parents connected to an 'afterMouseDownEventHandled' event that the floating component signals after dealing with it? Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: developing with / for internet explorer
Drop the alerts, and liberally log() your way through the app, then use MochiKit's logging bookmarklet. MochiKit.Logging - we're all tired of alert() Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.createDOM problem.....
On Jul 15, 2006, at 12:31 PM, Andrew wrote:
Hi,
I have just downloaded the latest, svn, version of MochiKit and am
using it (packed) in conjunction with dojo 0.3.1. I attempt to
create a
new DOM like so:
MochiKit.DOM.createDOM(data) - data being an xhtml document
and I get the following error message via FireBug:
uncaught exception: [Exception... String contains an invalid
character code: 5 nsresult: 0x80530005
(NS_ERROR_DOM_INVALID_CHARACTER_ERR) location:
http://127.0.0.1/dojo/dojo.js Line: 2960]
What is the issue here and how do resolve it?
That's not how createDOM is used. The signature is:
createDOM(name[, attrs[, node[, ...]]]):
where 'name' is the string representation of the DOM element tag
name, 'attrs' is an object, and zero or more sub-nodes created the
same way.
If data is just an XML blob, you'd be better off setting it as the
innerHTML of another node (perhaps). Without more idea what you're
trying to do, it's hard to say:
var my_div = createDOM('div');
my_div.innerHTML = data;
Zac
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.createDOM problem.....
On Jul 15, 2006, at 12:58 PM, Andrew wrote: Hi Zac, what I'm attempting to do is getting the returned page from a submit and then taking out element output which is the id of a div tag in the returned document. So it's basicall the other way round of what you have mentioned: Doesn't matter if it's the other way around. createDOM doesn't take an arbitrary bundle of XML. It takes the name of the DOM node you're trying to make. my_doc = createDOM(data); dojo.ById(myDIV) = my_doc.getElementById(output); Still not gonna work. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.createDOM problem.....
On Jul 15, 2006, at 1:28 PM, Andrew wrote:
Hi Bob,
you are correct. What I was after was:
xml = dojo.dom.createDocumentFromText(data);
divList = xml.getElementsByTagName(div);
dojo.byId('output').innerHTML =
dojo.dom.innerXML(divList.item(2));
Just wondered whether there was a nicer, more intuitive, way of doing
things in mochikit?
var my_unattached_DOM_node = DIV();
my_unattached_DOM_node.innerHTML = data;
divList = getElementsByTagAndClassName('div', null,
my_unattached_DOM_node);
...
then, my_unattached_DOM_node should have the structure of the
arbitrary XML you're looking for.
Zac
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~--~~~~--~~--~--~---
[mochikit] Re: Proposed Patch for Sortable
On Jul 14, 2006, at 3:19 AM, Thomas Hervé wrote: That's great, I'm glad you find it good :). I just want to warn you, try to test your solution on older machines before making an Internet app (opposed on Intranet) using more than 100 elements in Sortable. This is an intranet app, which is why I said we have legitimate use cases, and its impact is acceptable. We've modified our application build out to patch Sortable, and we're comfortable with our hack, so I guess it's moot. :^) Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Proposed Patch for Sortable
On Jul 13, 2006, at 11:38 AM, Thomas Hervé wrote: It's interesting, but I think you may run into other problems with so many sortables. Have you checked the performance of your solution ? I suspect the page become very slow, because Sortable is not designed to handle so many items. It's never gonna get to a point of handling so many items if improvements aren't considered. We have legitimate use cases for such large groups (even if, ultimately, we'll be dealing with much smaller subsets). Again, I think Sortable is mainly a proof of concept for DragAndDrop, and fits for simple cases. If you have lots of items or a complex layout, a hand made system (based on DD) will definitely be better. For example, you may try to define your Draggable on the fly ? The rest of the Sortable code works perfectly fine with such large groups (at least within our bounds), and I can't imagine this would be an impact for very small groups. I, for one, find Sortable to be an extremely valuable addition, and would hate to see it permanently regarded as merely a proof of concept. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Dollar shortcut for document.getElementById?
On Jul 12, 2006, at 7:45 AM, Peter Mularien wrote:
Thomas Hervé wrote:
Yes, there is $('id'), though not advised, getElement('id') is a
preferred form.
Just curious, why is the $ form not advised? I don't recall seeing
that
mentioned before.
It's right at the top of DOM's API reference[1]:
API Reference
Functions
$(id[, ...]):
An alias for getElement(id[, ...])
Availability:
Available in MochiKit 1.3.1+
Zac
[1] http://mochikit.com/doc/html/MochiKit/DOM.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~--~~~~--~~--~--~---
[mochikit] Re: Dollar shortcut for document.getElementById?
On Jul 12, 2006, at 7:45 AM, Peter Mularien wrote:
Thomas Hervé wrote:
Yes, there is $('id'), though not advised, getElement('id') is a
preferred form.
Just curious, why is the $ form not advised? I don't recall seeing
that
mentioned before.
Sorry, I read that as advertised. Ignore my previous message.
As far as advised goes, Bob had mentioned before that he added it as
a convenience for Prototype users, but since, as he pointed out
earlier, all the functions that act on DOM nodes will also act on
their id strings, there's almost never a need for it, and he prefers
the more verbose getElement() in the cases where he does.
Zac
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~--~~~~--~~--~--~---
[mochikit] Re: Dojo (javascript toolkit)
On Jul 11, 2006, at 1:05 PM, MAria wrote: Hello, I'm trying to do something with dojo, but there is no way! The first question is: I have dojo-0.3.1-ajax version, is it the last one?? This is just a folder, I haven't installed anything else. And to use it, I just include this line at the top of my .html document: script type=text/javascript src=../DOJO/dojo-0.3.1-ajax/dojo.js /script script type=text/javascript dojo.require(dojo.widget.*); dojo.require(dojo.widget.Toolbar); /script And the problem is, an error occurs, in mozilla console appears: dojo is not defined. You might try a Dojo mailing list. http://dojotoolkit.org/mailman/listinfo/dojo-interest Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: HTML and DOM
On May 25, 2006, at 8:00 AM, coredump wrote: Yes, it worked like a charm for my br tags, but if I allow a hrefs... and b/b the thing start to get ugly. Mainly because br is a simple tag, but the other ones have opening and ending parts... Any other ideas? On how to spit DOM vrom HTML quickly? :P myMochiKitDOMNode.innerHTML = stuffIGotFromTheDatabase; Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: MOCHIKIT VISUAL
On May 17, 2006, at 4:28 PM, Jose R wrote: information is basic and if the information is wrong... better dont have the info i think if all we wanna make of this library compete with prototype, mochikit developers have not only to emulate or copy prototype functionallity (as with visual effects module in mochikit) you have to be better than it! I think you miss what really makes MochiKit stand out from other Javascript frameworks. i think prototype with visual effects extensions (rico / scriptaculous) are best option for production applications for now I think frameworks with tests and documentation trump any pretty clicky-flashy out there. Zac --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] can we optionally get formContents to include empty form elements?
The Zope 3 formlib chokes when all the attributes specified by a Schema interface aren't present (that haven't explicitly been omitted from the view). But MochiKit eliminates empty form elements from the result of a formContents. Any chance we can optionally get it to include those as empty strings, or the like? Zac
