I'm trying Rails in RubyMine 2016.2.4. How to use the code completion for model's attribute name? In Yii2 the model's attributes are listed in comments
Internal structure and philosophy of Rails are different than Yii2's. Current database state is stored in separate special file called db/schema.rb. This file is automatically updated every time after applying new migrations and not intended for manual editing. In Yii2 you need to synchronize PHPDoc comments with current DB state manually. From the other side in Rails you can't see which attributes model contains just by looking at the model (the model code is very laconic in terms of that though).
Not sure, but I think for model attributes autocomplete RubyMine extracts column names from according table from that file. Read more info about db/schema.rb in official docs.
Also there is dedicated help section in RubyMine docs about Rails-Aware Code Completion.
So it works, but probably in specific places.
And last but not least check this related SO question. RubyMine provides very good autocomplete options, but don't hesitate to peek at db/schema.rb if needed or use DB managing tools to see column names and data during development.
Related
I am relatively new to Grails and I am little disappointed with the way _form.gsp removed with field plugin in Grails 3. _form.gsp seemed to be good time saving option when we need to customize views with Bootsrap or materialize.
Now with grails 3, install-templates does not create _form.gsp. As per this documentation, we can achieve customization by creating _wrapper.gsp, _widget.gsp etc under view/_fields/default directory. But I am not able to find the example of such custom GSPs.
Also, let's say if I customize all the four GSPs (_wrapper.gsp, _widget.gsp, _displayWrapper.gsp, _displayWidget.gsp) will it generate actual code when we run generate-view command? I mean will it replace, f:all, f:table etc tag with actual code? If not then there is quite amount of work to do I guess. Because after we are confident about our domain class and tested all CRUD operation, we run generate-view command for creating all the domain specific GSPs. Then in most cases, we need to do some changes according to our requirement, like re-ordering the fields, hiding some of the fields
So in conclusion I have two goals:
Customizing default templates and start developing.
When I run generate-view, I do not want f:all, f:table etc abstract tags. I need actual fields in place so that I can customize generated views of domain.
If any one has achieved this, then please share the solution.
Grails 3 comes with the fields plugin by default. The templates used in Grails 2.x have been replaced in full. So, your goal 2. will be hard to achieve with Grails 3 it seems.
However, here is a helpful blog which explains how you can adjust some of the fields templates by replacing them in your project: http://blog.anorakgirl.co.uk/2016/01/what-the-f-is-ftable/
Similar to the description provided, you can place a modified _list.gsp template in folder in
/grails-app/views/templates/_fields/
Hope it helps.
I am a newbie in MTurk, and I am trying to create a very simple Categorization Project via their Requester UI (rather then the API).
Each batch I use has 10 items (question and possible answer). I have searched their documentation and forums with not help and so I have several questions:
When i use their Standard Categorization template, I have no option for modifying the HTML and layout (as shown for "Tagging of an image" project). the only formatting options are for the categories, instructions and includes/excludes. Is there a way to edit the HTML of the standard template they provide?
In the Standard Categorization template, while my input data file (csv file) contains 10 items, only 5 are shown (tried with 6, still only 5 are displayed in the preview). Is there a way to change this limitation?
When I try to use the "Create HITs Individually" (rather than the standard template, as explained above), I have the "Design Layout" options, but I cannot find a way to make the questions in the "form" required (which is possible via the API). Is there a way to achieve this?
If you stick to the standard project templates, you can't modify them. That's the reason to create HITs individually (through the RUI or via the API).
You'll have to show us your CSV file, because it's not really clear from your description what the issues could be.
Your third question is unclear, but basically for creating HITs individually, you simply do standard HTML markup and put in ${variablename} placeholders wherever you want one of your CSV upload variables to be placed.
If your project is at all large, I would definitely recommend going through the API. It's simply much more flexible than the RUI for creating any kind of customized design.
I am in the process of learning Yii framework. I have always previously built plugins in wordpress and I have never used a PHP MVC framework before.
Assuming I have designed my database
Used Yiic shell - console to model the db and create crud classes etc.
Modified the controllers and views to my custom requirements.
Now the client requirements change and an extra field is required in the database.
I modify the database to add for example "tel2" field to the customer table.
Do I need to update the model, view and controller manually to incorporate these changes or do I save customisations then get Yiic shell to re-scaffold the model, view & controller, then re-write the customisations manually?
I am sure that I can do either, but is there an easier way / is there a way in which you all work which makes your lives easier?
This was a question on my mind also when I began Yii.
The simple answer to it is you dont have to change everything. The Gii module is a really powerful feature of Yii and after making the CRUD and the model after a DB table, and if you have your own custom functions and methods and then you decide that you need to alter a table and add a new column to it, all you need to do remake the model in gii and it shall show the the modified code in a seperate link tagged as "diff".
Gii only generates the code, it does not overwrite it.
Now all you need to do is open up the "diff" make sure that you do not overwrite the code as there would be an overwrite button as well. After you check out the "diff" code, it shall show the new columns and the new properties highlighted, now all you need to do is copy the requisite changed code into your original code.
This way, you can do as many changes as you want with everything remaining intact.
There is also another method. You can use a base class and extend all your code into another file. This way, all you need to do is change the base model and everything still remains intact.
I think this should have answered your question.
Regards,
You should look at gii as a tool that gets you started quickly. But once you created your models and maybe CRUDs you can usually forget about it. Your project code evolves and - if it's not a very simply project - you will have a lot of manual changes to the auto generated code anyway.
So every time you touch your DB you will update the related files. Often this only involves to add a new attribute rule in rules() in your model, and adding another input field to the form view.
I'm new to Doxygen and I'm trying to document an API I am planning to open source. I'd really like to build two sets of documentation, one for end users of the API and one for those who intend to modify it. Is there a way to tag Doxygen comment blocks in a way such that I can generate "user" and "dev" documentation trees? Is there a better solution to my problem? Thanks!
Depending on how your code is structured, you might be able to get away with using two Doxygen config files each including separate source files. The "user" config file would only list the source files containing the public interface to the API, while the "dev" config file would list all source files for the whole project.
This does mean that all your interfaces (e.g. abstract base classes) will need to be documented with the user in mind, but that is usually not a problem as by definition there is unlikely to be any implementation details in an abstract base class.
All your "dev" documentation then sits in the actual classes implementing the interfaces, which are never seen by the API and can be safely omitted by the "user" Doxygen config file.
Of course if your code isn't structured this way it's not going to work, so the only solution I can think of is to fill your comments with a bunch of conditional statements.
In addition to what Malvineous already said, there is the \internal doxygen command.
\internal lets you hide or show part of the documentation by changing INTERNAL_DOCS in the Doxyfile
More information here: http://www.doxygen.nl/manual/commands.html#cmdinternal
I've been tasked with maintaining an application originally written in VB6. It has since been imported into VB .Net and to say the least the code is anything but Object Oriented. The code is riddled with classes which contain nothing more than Public Shared attributes(variables) and methods(functions), the result of which restricts the application from opening more than one project at a time.
A project consists of a XML file which contains general project settings, as well as the location to an Access database which contains other project related data. Over the years the format of the XML file has been modified, and an update and versioning strategy has been adopted. The chosen strategy performs an update upon open whenever an old version is encountered. Thus far, updates have only consisted of rearranging data within the XML file or making database schema changes and moving data from the XML file to the database.
Having quite a bit of background in OOP it's easy for me to see that a project should be a self contained object which other objects interact with. However, I fail to see how to apply the chosen update strategy in OOP.
The problem of implementing the chosen update strategy in OOP has kept me from using OOP as of yet. If anyone has experience with such a task, or recommendations on how to proceeded I'd appreciate any assistance you can provide.
Build a class which reads the XML file in, and provides properties/methods/etc based upon the data in that file. When the class writes the XML file back out, have it format in the manner needed for the new version.
So, basically, the class will be able to read in the current version, plus all the older versions, but it will always write out the new version.
Data would be held in internal variables of the class, rather than having to scan the XML file every time you need something.
Adding a VERSION node to your XML file will also help in this case.
You might have answered your own question when you used the word strategy (i.e. the Strategy Design Pattern).
Possibly you could:
Create a project class that knows nothing about conversions but accepts a strategy object.
Create a hierarchy of classes to model each possible conversion strategy.
Use a factory method to build your project object with the right strategy
I don't understand why this is a troubling problem. It could be solved in any number of ways.
If you want to do a full object oriented enterprisey type thing, you could take any subset of the following solution:
Create an interface IProject which
describes how other objects interact
with a project.
Create the current implementation of
Project which implements IProject
and can read and write to the
current version.
Extend Project for each past
version, overriding the xml and
database read methods and having the
constructor call write when these
classes are instanced
For extra enterpriseyness, create a
ProjectFactory, which detects the
version of the file and instanciates
the correct version.
If further versions are needed,
rewrite the current Project to do
the same thing as past projects,
accessing the new version of Project
with all the reads and then calling
write.
The advantage of this solution is that you can continue meandering about with different versions and each new version only requires the ability to be updated to from the previous version, with all previous versions cascading up to the second to last version.