I found an unexpected issue while attempting to load a block within a magento module. The block name was *Mycompany_CustomerModule_Block_CustomerModuleDashboardDataBlock* (yes, the name is very long, but I added the module name all blocks related to the module to avoid confusing a dashboard.html with the one used by Magento Core).
The issue is that, if I try to load such block, with the following command:
$this->getLayout()->createBlock('customermodule/customermoduledashboarddatablock')
Magento raises the exception "Invalid block type". I couldn't figure out what was wrong, since I copied the whole file from a block that works perfectly, and then I tried renaming the block to something shorter, such as simply DashboardDataBlock. With the shorter name, block is loaded correctly.
My question is, therefore, are there any limitations in the length of Classes' names? I can always shorten the class name, but I'd like to know if there are limits so that I can avoid having similar issues in the future. Thanks.
The problem is, regardless of file system case-sensitivity, that the last part of Magento class name must not be camel cased.
MyNamespace_MyModule_MyClassName NO
MyNamespace_MyModule_myclassname NO
MyNamespace_MyModule_myclassName NO
MyNamespace_MyModule_Myclassname YES
MyNamespace_MyModule_My_Class_Name YES
You will notice this pattern in core modules, too. Class prefixes of namespace and module are read from the configuration files and can contain arbitrary upper case letters. But the actual class names are derived from the class alias in a way that does not allow upper case letters (have a look at the code in Mage_Core_Model_Config::getGroupedClassname() if you want to know, why. Hint: it uses uc_words)
There could be a couple of things at play here. If you are on a case-sensitive filesystem, then the issue is that you need to match camelCasing between your filename and class ID (customermoduledashboarddatablock in your case), with the note that the first letter of any folder or file which is resoled by the autoloader will need to be uppercase regardless of class prefix or class ID. Additionally, note that PHP does not care about casing of class names and method calls - only the autoloader cares, and only on case-sensitive filesystems.
The other possible issue could be total filename length in a Windows environment.
Related
Passing standard Windows file paths like C:\Foo\Bar.mp4 to methods like IMFSourceResolver::CreateObjectFromURL() works fine here but I'm wondering if this is allowed because, strictly speaking, C:\Foo\Bar.mp4 is not a URL. It would probably have to be translated into something like file:///C:/Foo/Bar.mp4 in order to qualify as a URL.
Still, for simplicity's sake, I'm wondering if simply passing a path name is ok as well or is this something that just happens to work but should rather be avoided?
I'm wondering if simply passing a path name is ok as well or is this
something that just happens to work but should rather be avoided?
No, this is not an accident.
From IMFSourceResolver::CreateObjectFromURL,
For local files, you can pass the file name in the pwszURL parameter; the file: scheme is not required.
Note : This method cannot be called remotely.
I have some code which has worked in multiple installations for about a year. Today im doing a small change to a control and then another control seems to have developed an issue. When at runtime im getting a 91 error object variable or with block variable not set.
I therefore looked at the problem line which is: -
If Screen.ActiveForm.name = "frmFoutmelding" Then Exit Sub
so I noticed the name was lowercase. if i delete .name and rehit the "dot" then it shows me i can use .Name but as soon as i move from this line it drops back to .name
I've checked for instances of name and it appears everywhere in the code in different modules but i cant find if i have accidentally defined this lowercase name anywhere?
Googling doesn't seem to show much but i feel Im googling the wrong terms
chaps - thanks for your suggestions - this was the first instance of the lowercase name and searching as Jim suggested didn't reveal anything I'm afraid. What I did discover was that this was suddenly being run before any forms had actually been displayed and so the count was 0. I therefore, did an on error to check the form count and exit the sub if it =0 then if not to carry on with the line I thought I was having issues with.
It's likely that you did create a new variable or property called (lower case) name, or that some included reference did the same. It's possible to use reserved words as variable names in some cases, but it requires taking specific steps.
I would first search your code for instances of name As to see if you created a variable (this assumes you use Option Explicit, which is a must IMO). Then search for Property*name with * as a wildcard.
If those fail you could try unchecking references or components to see if any of them define name. If none of that finds anything, please post back here.
Jim Mack covers a lot of the potential issues. I think another is if you typed a lower case '.name' in association with Activeform at some point earlier in the same code module - the VB6 IDE checks in the current module and uses that to define what case to use. Look further up the same code module (sub or function).
Ultimately, check what changes you made by comparing the old source to the new in a file comparison tool like windiff - you do have backups, right?
Is there a way to prevent Guard to run all the watchers that match a file structure but only the first one?
I basically need to instantiate a different object if the file copied in my root folder has a specific structure or not. For instance, if the file name matches \d{2}-\d{6}_\d{5}_\d+_\d+.csv I need to instances object A while for all the other .cvs files object B.
As first attempt I was trying to use negative lookbehind but due to lookbehind limitations it looks like I cannot do that.
So, now I'm trying to force Guard to execute only the first watcher that matches.
My Guardfile looks like
guard :my_csv_files do
watch(%r{^\d{2}-\d{6}_\d{5}_\d+_\d+.csv$})
end
guard :others_csv_files do
watch(%r{^.+.csv$})
end
Thanks
This has been available for a while, but was never documented. (Until today).
There's a :first_match option, which does exactly what you want:
https://github.com/guard/guard/wiki/Guardfile-DSL---Configuring-Guard#guard
I am looking for a way to separate the repetitive html codes from web pages, and for this I am planning to use the macro functionality. The problem here is for every macro I need to put this macro in a file, or put some of them in a file and include this in the template file.
What I need is to include once just the directory name something like
<#import "/tags/widgetDirectory" as widgets />
here the /tags/widgetDirectory is a directory , and every files here can be seen as a macro defined.
when I need to insert a code part from a file from this directory lets say slide.ftl I will just use
<#widgets.slider />
the system will check for slider.ftl in the /tags/widgetDirectory directory . here the slider.ftl can have <#macro> as first and as last line , or these can transparently added and system can load it as a macro
this will easy my designer work.
Maybe there is better way for doing this kind of widgets/components based web design ?
best regards,
This feature (importing directories) is something that's planned for FM actually... but it won't happen anytime soon. But I guess it can be solved fairly well with a hack right now. Instead of #import, use your own TemplateMethodModelEx, that you could use like <#assign widgets = importDirectory('/tags/widgetDirectory') >. This will return a TemplateHashModel that's also implemented by you and is bound to the directory path. When an item of that hash is get, it uses Environment.getCurrentEnvironment().include. The included file is expected to create a macro with name __main or something. So then you get that variable with Environment.getCurrentNamespace().get("__main") and return it as the result of the hash lookup. Of course this hash should also maintain a cache, so that if the same item is get twice, it wont include the template for the second time, just return the macro extracted earlier. This can be developer further, so that if the include file didn't define __main, then it's supposed that it prints directly to the output, and so it will be included again, when the "tag" is called again.
The following code snippet is how I am handling routes in my Sinatra application. All of my views are contained in my views/pages directory. These are just haml files that represent static html, with some javascript. Are there any negative implications to loading views in this manner? If the page does not exist, it throws a file not found error. I am worried this is somehow an attack vector.
error RuntimeError do
status 500
"A RuntimeError occured"
end
get '/:page' do
begin
haml "pages/#{params['page']}".to_sym
rescue Errno::ENOENT
status 404
"404"
end
end
I'm not sure if this is a security concern here (I'm not that into all the details of Sinatra) but I tend to be paranoid when using user specified data like for example params['page'] in your example. As said I'm not sure if Sinatra sanitizes the content and would make this example impossible, but imagine it said something like ../db_connection.yml. So Sinatra would be told to load the haml file pages/../db_connection.yml which might actually exist and display it to the user showing them your database configuration.
If you don't have any weird symlinks in your pages directory it would probably be enough to replace all double occurences of a dot with something like .gsub(/\.+/, ".") of the passed string (or replace all dots if you don't need them in the name to be even more paranoid). I'm not sure if there are any multi-byte insecurities where someone could do something ugly with encodings though and it might be useless to do the replacing at all because the exploit would work nevertheless.
Edit: Short reading into the Sinatra manual yielded that
By the way, unless you disable the path traversal attack protection (see below), the request path might be modified before matching against your routes.
So it seams that it should be secure to just use the params value without any special filtering, you may however like to look into the documentation some more (especially the security sections). However I don't think it's too much of a security issue if it's possible to figure out if a file in your pages directory exists or not.
Are there any negative implications to loading views in this manner?
Time would be one, it takes a lot longer to generate a page than to serve a static one. Resource use would be another for the same reason. Added complexity another. Reinventing the wheel would be another.
Why not just put static pages in the public directory? Or why not use a static site generator?
Pick the tool that fits your needs, and don't reinvent the wheel (especially when the framework has already provided you with that wheel!)