I have one companion script file for a Rails model, that uses code I've broken down into a hierarchy of over a dozen classes, for things like jQuery/Bootstrap UI code, factoring out similarities between different types of dialog, and so on. Let's say I'm working with articles.js.coffee as the "main page script" here.
I can define Coffeescript classes, namespace them as something like window.ourproject.OurUIDialog, and save them in separate, per-class source files such as app/assets/javascripts/OurUIDialog.js.coffee. Restart the Rails server, and that class can be subclassed, e.g., window.ourproject.PostInfoDialog extends window.ourproject.OurUIDialog. As long as PostInfoDialog is in articles.js.coffee (where the instantiation of the PostInfoDialog is), all is well.
But, if I move the subclass (PostInfoDialog) out into a separate file, e.g., PostInfoDialog.js.coffee, then attempting to do anything at all with it within the main articles script produces
Uncaught TypeError: Cannot read property 'prototype' of undefined
Again:
This revolves around a Rails model's companion script file, here called articles.js.coffee;
window.ourproject.OurUIDialog gets picked up whether it's in its own file or in articles.js.coffee
window.ourproject.PostInfoDialog (which extends OurUIDialog) can only be used if it's not in a separate file, even though viewing the generated HTML shows PostInfoDialog being included with all the other script files.
I'm tearing my hair out trying to figure this out, and I didn't have much left to begin with. Any ideas?
Pretty sure that Trevor Burnham answered my question when he answered this one; I just didn't see it the first dozen times I searched. :-P
Thanks to both of you for reading this one, though. :-)
Related
Upon running rails g graphql:install, a set of useful base type files are created in /app/graphql/types for us to extend when defining our own types. When running any of the generators, it creates these files in the same folder also. I set about creating sub directories thinking I could add some sense to this giant catch-all directory, but couldn't get things to load properly.
Since there is a base file for each type (base_enum.rb, base_object.rb, etc.), I created a folder for extensions of each of these types (enum_types, object_types, etc.). This broke auto loading though and I had to explicitly import these files to be able to use these custom types. So, at the top of query_type.rb, mutation_type.rb and app/graphql/mutations/base_mutation.rb I added the following:
['enum_typs', 'input_object_types', 'interface_types', 'object_types', 'scalar_types', 'union_types'].each do |dir|
Dir[File.dirname(__FILE__) + "/#{dir}/*.rb"].each {|file| require file }
end
This allowed things to run, but any change would break auto loading so I would have to restart the server on each change. I started reading through this article about auto loading on the rails site, but it was quite honestly a little over my head. Though it led me to believe I had to either find the correct names for my folders or namespace the objects defined in my type definition files properly to be able to do this.
Is there a sane way to organize these files in sub-directories which doesn't break auto loading? Do most projects just have a flat folder structure for these files?
Thank you!
rails 3.2
I am new to slim, and I have to work with an application that's using it. Reading through some documentation, I see that using something like:
.class
which translates to:
<div class="class"></div>
In the code I inherited, in the .html.slim file, I have:
.form-section.customer_info
When I look through the stylesheets folder, I cannot find customer_info, but I can find form-section.
Shouldn't I be able to find customer_info in one of the stylesheets?
The answer is maybe you can find it in a stylesheet. But there are other cases, where you may not:
Sometimes a class is used as a target for a JavaScript snippet; if you find it mentioned in the javascript for the app, then you likely want to keep it because an interaction may depend on it (read the JS code to determine this).
Sometimes, the class has been removed from the stylesheet and not removed from the code; in this case you may remove it.
However, sometimes a class is added to mark the section of HTML as semantically significant so that styling can be applied to it at a future time; in that case, you may choose to keep it.
For instance, for better or ill, when I am writing code, I will name sections using classes, as .user-list or .part-table to indicate that, as the coder, I know the HTML code is going to contain users or parts. By doing this consistently I can mark out portions of the front end for later consistent styling by usage; that is, all the part tables can be styled the same way, all the user lists can be styled the same way, etc. Again, this is a convention I have seen used and that I practice. Nonetheless, these represent a few reasons why a class may be present in the HTML, but not referenced elsewhere.
The question:
How do I get somthing like that in coffeescript
modules_list[some_calculation(__FILE__)]=a_local_class.new
I have a module manager, that handles all my coffeescripts (js) at runtime - i.e. while in browser, that means:
I have
many modules, not all are in all situations loaded 'statically'
only some have dependencies
module manager resolves things like init and dynamic reload (ajax)
and dynamic init
A module looks like this in prinzip:
class Book
constructor: ->
...
init: =>
$$$.get_module('BookReader') #<- ajax loaded if not already
later_on: =>
$$$.get_module('LetterCounter').count_letters(#) #<- ajax loaded if not already
...
#$$$.modules_list['Book'] = ->
new Book
this all works (very) satisfying.
But I have a rendunancy in my Logic, because a 'module', has a module name, a class name and - thats the point - a file name
the class name is - thats clear - not a problem, I could name all 'Foo'. Its only not nice to do that.
But modulename ( modules_list['Book'] ) and the coffee- (js-) file name are redundant in sence of Rails CoC.
Any ideas how to get
#$$$.modules_list[some_calc(__FILE__)] = -> new Book
i was there, and there may be a solution for me, but if, I dont understand it.
thanks in advance
ps.: for those who want to know "why I do this":
I have 3 completely different apps for 3 different customers, I am far away to say what is the base for all, 2 apps a realy big with a huge amount of js, that is not always needed so I want to reload it dynamicaly. I "help" asset pipeline a bit with putting all files (staticaly) used in a single one without the ones I was working on the last 20 mins (dynamicaly) for better debugging, and I get rid of all (down-)load ordering problems
There is no need for __FILE__or something like that, in that case. I see that now. It would be the wrong direction of naming.
Its the same 'problem' that you have with Rails it self. If you have
module Base
class Fun
your filename should be base/fun.rb not vice versa!
The Filename resolves out of "its content" not the other direction.
I've been searching and trying to learn for ages but it just doesn't stick. There seems to be only 1 tutorial on Zend 2, and it's not very smart. Here we have a sample structure (and the tutorial proceeds with this application) http://framework.zend.com/manual/2.0/en/user-guide/modules.html :
zf2-tutorial/
/module
/Album
/config
/src
/Album
/Controller
/Form
/Model
/view
/album
/album
That's not cool - how do I know which album is which? In Zend 1 it made a lot of sense - you have modules, then you have controllers, and those controllers have actions.
Now I have a module called Album. is the src/Album/... a "single controller"? Would:
zend1application/modules/album/albumcontroller.php map to zend2application/modules/album/src/album/controller/albumcontroller.php? In that case, why are there 3 albums now? Like what happens if I change albumcontroller.php to indexcontroller.php? (I have been testing but there are so many changes it never sticks - I finally thought I should ask someone and if I know why I'll remember.
If I look at it a different way it seems the Album in module/Album and module/Album/src/Album should be the same - then why would we have it twice? Doesn't that just make room for error? Like why have a src/album folder? Why not put Controller, Form, and Model under module/Album?
Why is there a folder called Controller? There used to be a folder called controllers (plural, why singular now?) in a module before, that makes sense. But why is/are controller(s) inside a src/Album folder now?
Thank you for your time. I have tried to research but I think it's just too big absorb when (in my opinion) it seems so sparsely documented. Or, if someone could point me to a book like http://survivethedeepend.com/ but for ZF2, it'd be greatly apprecated.
Zend Framework 2 follows PHPfigs PSR-0 Standards. This means that the directory structure directly relates to the classname. But before i come close to that, let me explain the basic architecture.
First you have the ModuleNAME. Since the Module name needs to be unique, it only makes sense to map the Modulename to the Namespace of your model.
Inside the modules folder you have three sub-folders. One folder for configuration items named config. One folder for source-code files named src and one additional folder for the view files view
This separation is simply for overview. You separate configuration, view and sourcecode from another. It makes no sense to bunch them together and i guess you'd agree. This pretty much has been the same for ZF1, too.
The interesting part is the source-folder src. Earlier i mentioned about the PSR-0 Standard. And this is the place where it comes into effect. By default the source-files for each module will be looked upon from the source-folder src. So whenever you have a class, it will be using PSR-0 Standards based off of the source-folder. Mewning: My\Funky\Class would be found within src\My\Funky\Class.php
And that's basically all there is to it. Controllers usually have a FQCN like Mymodule\Controller\SomeController so you will find this class inside src\Mymodule\Controller\SomeController.php
The main question arising could be: Why are the folders sometimes all lowercase and sometimes ucfirst. The answer, once again, is PSR-Standards. Classnames and/or Namespaces are supposed to begin with an upperchar character. And since path-names are case-sensitive, the folders need to match the classnames exactly!
EDIT Another nice read i've just stumbled upon is Rob Allens latest blogpost: Thoughts on module directory structure. He explains how you can change the default setup quite easily to your likings.
I've been learning Ruby/Rails with vim. Tim Pope's rails.vim seems like a really good tool to traverse files with, but I keep getting these pesky "E345 can't find file in path" errors. I'm not vim expert yet, so the solution isn't obvious. Additionally, I've tried this and it doesn't apply to my problem.
As an example of the problem. I have a method format_name defined in app/helpers/application_helper.rb and it is used in app/helpers/messages_helper.rb. Within the latter file I put my cursor over the usage of format_name and then hit gf and I get that error. Similar disfunction with commands like ]f and [f
However, it works sometimes. I was able to gf from user to the app/models/user.rb
Ideas?
I think that is a limitation of rails.vim. It does not support “finding” bare methods. Supporting something like that would require one of the following:
an exhaustive search of all the source files for each “find” request
(which could be expensive with large projects),
“dumb” indexing of method names
(e.g. Exuberant Ctags and gControl-]; see :help g_CTRL-]), or
smart enough parsing of the code to make a good guess where the method might be defined
(which is hard to do properly).
If you know where the method is, you can extend many of the navigation commands with a method name:
:Rhelper application#format_name
But, you do not have to type all of that in. Assuming the cursor is on format_name you can probably just type:RhTabspaceappTab#Control-R Control-W (see :help c_CTRL-R_CTRL-W).