.get mootools method not working in joomla 1.5 - mootools

i have a problem in joomla 1.5.18. i'm trying to get text from an element using for instance
var divContent = $$('#myDiv').get('text');
but each time i get the error, in chrome: Uncaught TypeError: Object #<HTMLDivElement> has no method 'get'; in firefox: divContent.get is not a function. why i'm getting this error?

even following samples in mootools i get the same.
i know how to do it for each object in the collection. i got doing $$('.') and using the "each" method:
$$('p.classname').each(function (el){
el.addEvent('click', function() {
var txt = el.get('text');
...
});
});
and obviously i add the function onto domready. i don't use jquery 'cause mootools & jquery stops the events each one... -i tried once & what i needed didn't work- and i wish to use all joomla resources including mootools.
checking the version in mootools.js it says 1.13 (?)

not sure which version of mootools comes in joomla 1.5.18, it may be 1.2.5. if so, .get should work but not as you expect it to.
You are probably a jquery user, used to $("#myid") and find that the only way to get similar results with the # in there in mootools is via document.getElements, aka, $$.
the problem is, to get a single item by id in mootools, you actually do document.id("mydiv") or even $("mydiv"). $$("#mydiv") will actually return a COLLECTION of elements with a single member, so [obj], so the real element is $$("#mydiv")[0].
if you apply a .get method to a COLLECTION, the getter normally iterates via a .each through all members and performs the get individually. it will return a new array member for each member of the collection - i.e. ["innertext"]; - though there should be a method for the collection, make sure that the element is there, it's in domready / onload and it's a unique id.
Still, I'd swap to using the $("mydiv").get("text"), it ought to be fine. This is all all too common assumption of jquery users that don't read the manual, in my experience. It results in bad and un-performant code due to all the .each iterations mootools has to silently do to work with the collection for you. Just saying.

You can also (and should) upgrade your Joomla to the latest version (security fixes, etc) and I believe it was about version 1.5.20 they included a newer version of mootools right out of the box (also there is a plugin for mootools upgrade you can enable). I believe the version included out of 1.5.20 is like 1.2.5 or something...
That may help!

Related

What should be done to get around or resolve the PrimeFaces exception requiring the definition of a lazy attribute or one that doesn't result in null?

I am in the progress of upgrading a legacy application from PrimeFaces 6.2 to 11.0.0 (which is the newest available with maven - https://mvnrepository.com/artifact/org.primefaces/primefaces). I have had to make a number of changes, including adding Object as the parameter for RowEditEvent and TreeNode objects (which are now generic) and changing instantiations of DefaultStreamedContent to use .builder(). Now, I am facing the following error whenever I try to run the application and navigate to certain pages:
"javax.faces.FacesException: Unable to automatically determine the lazy attribute. Either define the lazy attribute on the component or make sure the value attribute doesn't resolve to null."
It looks like an exception is being thrown rather than a warning as is noted in the conversation here: https://github.com/primefaces/primefaces/issues/8436. It also looks like it was fixed, but for version 12 (which is not on the maven central repository).
I am wondering what my options are, or what could be done about this. Should I go back to an older version?
As a workaround you could create an application factory which sets the lazy attribute to false.
See: https://primefaces.github.io/primefaces/11_0_0/#/core/globalattributes
Is it a lazy DataTable which uses LazyDataModel? If yes, just set lazy=true, otherwhise set lazy=false

SolidJS: "computations created outside a `createRoot` or `render` will never be disposed" messages in the console log

When working on a SolidJS project you might start seeing the following warning message in your JS console:
computations created outside a `createRoot` or `render` will never be disposed
There are some information available on this in SolidJS' Github repository issues. But after reading them I was still not quite sure what this was all about and whether my code was really doing something wrong.
I managed to track down where it came from and find a fix for it based on the documentation. So I'm providing the explanation and the solution for those Googling this warning message.
In essence this is a warning about a possibility of a memory leak due to a reactive computation being created without the proper context which would dispose of it when no longer needed.
A proper context is created a couple of different ways. Here are the ones I know about:
By using the render function.
By using the createRoot function. Under the hood render uses this.
By using the createContext function.
The first is by far the most common way, because each app has at least one render function call to get the whole show started.
So what makes the code go "out of context"?
Probably the most common way is via async calls. The context creation with its dependency tree happens only when the synchronous portion of the code finishes running. This includes all the export default function in your modules and the main app function.
But code that runs at a later time because of a setTimeout or by being in an async function will be outside of this context and any reactive computations created will not be tracked and might stick around without being garbage collected.
An example
Let's say you have a data input screen and have a Save button on it that makes an API call to your server to save the data. And you want to provide a feedback to the user whether the operation succeeded or not, with a nice HTML formatted message.
[msg,setMsg] = createSignal(<></>)
async function saveForm(){
...
setMsg(<p>Saving your data.<i>Please stand by...</i></p>)
const result=await callApi('updateUser',formData)
if(result.ok){
setMsg(<p>Your changes were <b>successfully</b> saved!</p> )
} else {
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{result.error}</pre> )
}
}
...
<div>
...
<button onClick={saveForm} >Save</button>
{msg()}
</div>
This will produce the above mentioned warning when the API call returns an error, but not the other times. Why?
The reason for this is that SolidJS considers the code inserts inside JSX to be reactive, ie: need to be watched and re-evaluated. So inserting the error message from the API call creates a reactive computation.
The solution
I found the solution at the very end of the SolidJS doc. It's a special JSX modifier: /*#once*/
It can be used at the beginning of a curly brace expression and it tells the SolidJS compiler to explicitly not to make this a reactive expression. In other words: it will evaluated once and only once when the DOM nodes are created from the JSX.
In the above example here's how to use it:
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{/*#once*/ result.error}</pre> )
After this there will be no more warning messages :)
In my case, I had an input and when that input changed I re-created an SVG drawing. Because the SVG creation was an expensive operation, I added a debounce in the createEffect function which ran when the input changed. debounce is a technique to defer the processing until the input stops changing for at least X amount of time. It involved running the SVG generation code inside the setTimeout function, thus being outside of the main context. Using the /*#once*/ modifier everywhere where I inserted an expression in the generated JSX has fixed the problem.

Efficiently find duplicate data property in object literal?

After creating our new system in Vue with babel, I have started testing compatibility towards older devices. Our babel is transpiling the source down to es2015 together with webpack.
I have now tested with browserstack against both Ios & android. Newer OS works on both platforms. However on android phones that use the default browser, I get an error in sentry stating; Duplicate data property in object literal not allowed in strict mode It does not give me any hints on where this might be thus making the debugging process painfully hard.
The only light in the end of the tunnel I can se now is the ios part. Ios devices that run IOS < 9 states an error Attempted to redefine property 'value'. also in sentry
If I am not mistaking, the ios issue is a reworded error of the same issue?
As I read over here, I suppose 'value' might be defined twice in a object or element.
This all wraps up to the question, how does one go with finding duplicate data properties?
Can you share some of your code (just the area from a few components?)
One thing to check is inside of data(), ensure you are returning an object. This happened to me when I started out with Vue.
Example:
// component a
data () {
a: ''
}
// component b
data () {
a: '' // ERROR! Duplicate
}
This happens because the data is merged on the main Vue instance. So in this case it should look like:
// component a
data () {
return {
a: ''
}
}
// component b
data () {
return {
a: '' // ok now
}
}
Hard to make any other guesses without some code.
I had the same issue reported on a old android device, here's what i did :
We had components with both mapActions(["something"]) and a defined method something() { this.$store.dispatch('something') }
So i removed the methods declaration.
It still didn't work so I check the build main.xxxx.js on eslint
and found some "Attempted to redefine property 'value'" on something like domProps:{value:t.value,value:t.value}
Looked up the code and saw that we had components with both v-model and :value and also some checkbox using v-model and :checked.
I only kept the v-model and it works.
It also seems like the problems could come from repeated props like stated here : https://www.tutorialfor.com/blog-267252.htm
I managed to find out what line the error occurred on and found out that a plugin that I used with name Vue-numeric had created a duplicate value:
domProps: {
value: n.value,
value: n.amount
},
I had accidentally locked the plugin on a older version where this problem was present. The issue was fixed by simply updating.
Thank you #xenetics for taking your time on this issue.
Yes, this is a restriction that was only in effect in ES5 strict mode, which these environments you have apparently use. It absolutely makes sense but was nonetheless loosened in ES6 because of computed properties - see What's the purpose of allowing duplicate property names? for details. That's why babel doesn't complain about it when transpiling.
To find these (valid but nonsensical) duplicate property names in object literals in your code base, you can use a linter such as ESLint with a rule against these.

Strange errors when linking to libmariadb

I'm currently develop an Objective-C library that links to the MariaDB C connector. I believe there is a problem with the library, though.
Every time I execute my code I get very strange errors on the console. The -(id)init method of my library calls mysql_init(NULL) to initialise the library but as soon as I return from -(id)init I get the following errors in the console:
Object 0x10643df70 of class XXX autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
Thing is, there is no multithreaded code being executed and if I run the same - (id)init without the call to mysql_init(NULL) the errors disappear. I believe the libmariadb library is causing these errors to appear. I don't get why though.
Do I need to build it with any special command line switches? Am I calling the right methods? I obviously used the MySQL online documentation as a guide.
Make sure you add this anytime you have a new thread:
#autoreleasepool {
//enter code here
}
Have you tried latest revision from launchpad?
Also try to build libmariadb with -DUNDEF_THREADS_HACK and
CMAKE_USE_PTHREADS:BOOL=OFF)
I was busy with other stuff for a while. I've since updated MariaDB to the latest version and, as far as I can tell, it works fine.

jquery 1.9 .ajax() datatype default changed?

Given an ajax call such as:
$.ajax(
{
url:"MyWebService.blah",
data: {"data":"awesome"},
success : function(responseText)
{
var myJsonObj = $.parseJSON(responseText);
//do stuff with myJsonObj
}
});
This was working fine. I updated jQuery to 1.9 today (I was on 1.6 for a while) as a possible fix to Safari all of the sudden not supporting various toggle functionality (something about eventLayer.X no longer supported), and now all my ajax calls are throwing the following javascript error:
Uncaught Syntax Error: Unexpected token o
After a little research and some testing, I discovered that "responseText" in my code above is now a JSON object, not a string. So the error makes sense, but I'm trying to wrap my head around this. Did jQuery really change the default return type? I checked the documentation:
http://api.jquery.com/jQuery.ajax/
and dataType is defaulted to "Intelligent Guess". I can see how that might be convenient, but I also don't like it.
So here are my questions:
Is this a new(ish) change in jQuery?
Was it version 1.9 that did this, or has it been this way before and I'm a fossil having been using 1.6?
What are some suggestions to handle this and sort of "future-proof" my code?
This is a pretty fundamental change that affects a lot of code. I will go through my code and remove any instance of parsing my returned data to JSON, but this whole thing is a little unnerving. Was I mistaken in not specifying a dataType? I suppose it is a good practice to enforce a dataType instead of relying on default, but... wow. Am I alone on this, or was that a tad presumptuous of a change on the part of jQuery?
jQuery automatically detects what the dataType is based on what was returned if no dataType was set. Most likely 1.9 just improved that detection to properly detect what you are returning as json. It's best to always give a datatype to ensure you'll always get consistent results.