I'm wondering if anyone has had any experience writing a Backbone application with Mootools as it's ajax/dom library instead of jQuery. I know it's possible but is it going to be a headache? Are there any gotchas I need to know about?
Well, I'm currently using a modified version of that MooTools adapter that #Dimitar Christoff linked here, which supports events.
I also modified that to use MooTools agent instead of Request, and after that I realized that I could write my own adapter so I can use all the new MooTools stuff (namely Prime, Agent, Moofx and Elements which comprise MooTools 2.0), that repo is here:
https://github.com/kentaromiura/Marrow
While it's still in alpha and the code is just hacked together to made the tests pass, it's seemingly working now.
I think that every bit of the original adapter has been replicated while other features work thanks to what is implemented into Elements and Slick.
Though, probably this is not what you meant by "MooTools", so I'll look into branching my repository and copying in all the changes I made to the original adapter.
Backbone need JQuery or Zepto... One of this is required for both DOM manipulation & Ajax...
Related
Do you know of a workflow that includes source maps for an app compiled with grunt?
I am well aware of plugins like uglifyjs that allow you to simply generate a source map. But I'm looking for incorporating this into a more complex workflow, rather than just making a one-off source map.
I've noticed that the most popular Yeoman generators (that I know of) are missing source maps in their workflows. Is this just because of a lack of support in the major plugins for source maps? Or is it instead that source maps aren't necessary in work flows, and I just can't think of a clever enough alternative?
Notable sources of trouble with popular grunt plugins that I've run into include:
uglify being unable to handle even the most basic of project structures without a hacky fix.
usemin also being unable to handle source maps beyond the simplest of configurations, in that it can really only support one per project (but still requires a hack to correct it). A possible solution is obviously to stop using usemin altogether, but then you lose out on all of the benefits of it, like pairing it with rev, watch, and connect.
I'm thinking that my best course of action might be testing with un-concatenated/not-minified sources when I'm testing my app. This is, of course, less than ideal, as I'd like my test environment to mirror the production one as best as possible.
Do you use source maps in your grunt project? How do you do it? If not, how do you get around the lack of support for them?
Updates 02/17/14
Z Goddard and I are working on fixing up source maps across the grunt-contrib suite. The planned options for the entire suite can be read about in this repo. We're also working on a new library, sourcemap-util, that will provide helper functions for generating source maps with any library. I'll update this when there's more progress.
I've done enough research to now be able to answer my own question.
No, there is not really any good way to handle source maps right now with grunt.
Both usemin and grunt-contrib-uglify need updates for this to work as I'd like. I submitted a pull request to grunt-contrib-uglify that is a good start on better source map support. With luck, this pull will be merged.
As for usemin, I disagree with its approach to handling dependencies. I've begun a separate project, grunt-resourceful, that goes about things differently. That project is still in its infancy, so I don't suggest using it now. I'll update this once 1.0.0 is released.
How easy it's to come up with a drag and drop web-based interface that'll provide me features to wire objects together, setup configurations nicely in a modal window for each object? I'm looking for links that've any similar kind of interface, or articles on this. also, i'm looking for your technology/language suggestions.
Another way I'm thinking - as a desktop appln + browser dependent addon..
Is it good to create such an user-interface using XUL, which can be deployed as an addon on Firefox/as a stand-alone application in Windows? Are there any other similar things/technologies which can provide a basic framework for us to build on it further?
Why do I need this, finally?
..for building simple Workflows, for defining process flows, that can provide me some auto-generated xml content which I can use for further processing.
Thanks!
I'm quite interested in this, too.
I've flirted with HTML5's DragDrop implementation - Quirksmode has Bad Things to say about that, so then I thought "Perhaps a JavaScript library can help me" - haven't checked out jquery for this yet, but I have checked out YUI's DragDrop, DragDropManager and DataSource, and its looking hopeful (consistent, reliable).
I tried things like adding an iframe on the fly to any document, to provide this kind of functionality without needing to add dependencies to the page given the iframe - mixed results, but in my case I was trying to cater for x-domain access, which proved difficult.
So I'd say JavaScript could be a winner - if designed poorly it could be difficult to manage resources though, if you want to potentially DragDrop/edit/config any element in a document - so watch out for that.
If you're keen and able, Adobe AIR apps also look promising - but I can't help with any more info on that, other than they're Desktop Apps with great flexibility.
I'ma going to keep an eye on your Question, I look forward to any other Answers/comments!
EDIT: I forgot to mention Flex (aka Flash Builder 4, latest version) is quite easy to create stuff like this, though I've had exposure to Flash for a while. It comes with the standard Adobe caveats; price, libraries, support.
Well, I've been following the NerdDinner tutorial online and I've completed it to a T.
Now I've implemented a project of my own using pretty much the same architecture.
I notice my process is:
Create database.
Create DBML.
Create |TableName|Repository.cs class with data access methods.
Create partial |TableName| class to handle validation.
Rinse and repeat for all tables.
By the time I'm done I'm exhausted and I haven't really done anything except drag and copypaste code and change variable names.
What am I missing here. Where can I improve this boilerplate haze I'm in?
Edit: Sans creating my own T4 template, is there a tool that will help me?
See Visual Studio Templates.
I haven't used them, but I assume if you take the time to customize them, you'll be able to make Visual Studio generate a lot of what you already do instantly specifically using the T4 template language/interpreter thats embedded in Visual Studio.
I haven't used it much but perhaps you could create a codesmith template to handle this. http://www.codesmithtools.com/
I have seen it used to good effect with Nettiers and in some other scenarios.
Have a look at this for ideas. It uses a generic repository and the unit of work pattern.
http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/
Also here.
Advantage of creating a generic repository vs. specific repository for each object?
I've implemented something based on these ideas. You may also want to look at using a service layer more interfaces etc than the nerd dinner example shows.
As good as the tutorial is, it isn't IMO really fit for use in an enterprise application as it is still quite tightly coupled.
Hope this helps.
I use my own tool for that: http://github.com/Necroskillz/NecroNetToolkit
It basically bypasses all the steps that u mentioned (except validation, because I have validation on my view models).
While its not directly MVC focused, I've enjoyed using NetTiers http://nettiers.com for this kind of foundation. We start with the Db tables and indexing and then generate the stored procedures and their related data and service layer code. After that we add our own custom stored procedures, creating a rich (and easily understood) foundation. Future changes are easily accommodated through this mechanism.
We also bolt the code generation into our Nant build procedures, providing a very quick way of updating all of the mundane 'plumbing' code, allowing us to concentrate on the interesting stuff.
We've just started working with MVC and have found the netTiers service layer works nicely with it - time will tell as our MVC experience grows. I hope that helps!
Create a framework!
I've been trying to find a good form of RPC to standardize on, but so far I've ran into a ton of walls and was wondering what the stackoverflow communities view was.
My ideal RPC would provide the following:
Somewhat wide support in other languages, in that people shouldn't have to write a custom stack to use our server
Input validation
Ideally, some way to turn the above input validation into some sort of automated documentation to distribute
Clean and maintainable code
I am a fan of the catalyst framework and would prefer to stick to it, but if there is a clearly better alternative for RPC servers I'd be open to that as well.
So far I have looked at the following:
Catalyst::Controller::SOAP
Doesn't appear to support returning of complex data structures, only string('literals'). I could probably serialize data on top of that, but that seems very hacky. It also lets you return a pre-formed XML object, but I couldn't get that to work and it looks like you'd need to re-create a lot of SOAP data structure for it to work.
I do like the idea of WSDLs, but the complexity of the overall spec also makes me wonder how well support for communicating with other languages will be.
Custom POSTing XML based controller
We tried to roll our own by hand in a similar way to how we've seen two other projects do it recently where there is a dispatch url that you post XML to. This lets you have XSD validation/documentation, but required creating a lot more code than we want to maintain at this point.
Catalyst::Plugin::Server::XMLRPC
Gave a warning about using a deprecated method that will be removed in a future version of Catalyst.
No input validation or doc creation, but otherwise the best I've found
JSONRPC
Looks pretty similar to XMLRPC only the module is actually updated. I'll probably go with this next unless someone suggests something better
There also appears to be two different modules for catalyst that do JSONRPC
I realize that REST isn't pure RPC (only a subset), but...
I would recommend the Catalyst::Controller::REST and Catalyst::Action::REST modules. They're frequently updated and the documentation is fairly good. There is also a good (but rather dated) example of using Catalyst::Controller::Rest in the 2006 Catalyst Advent calendar titled Day 9 - Web Services with Catalyst::Action::REST.
FWIW, Catalyst::Controller::SOAP does support returning complex data. Take a look at the documentation http://search.cpan.org/~druoso/Catalyst-Controller-SOAP-1.23/lib/Catalyst/Controller/SOAP.pm, which will show you that you can use a WSDL to describe your service. Also, see http://daniel.ruoso.com/categoria/perl/soap-today.html.en for a more detailed step-by-step process.
i have a big web application running in perl CGI. It's running ok, it's well written, but as it was done in the past, all the html are defined hardcoded in the CGI calls, so as you could imagine, it's hard to mantain, improve and etc. So now i would like to start to add some templating and integrate with a framework (catalyst or CGI::application). My question is: Somebody here has an experience like that? There is any things that i must pay attention for? I'm aware that with both frameworks i can run native CGI scripts, so it's good because i can run both (CGI native ad "frameworked" code) together without any trauma. Any tips?
Write tests first (for example with Test::WWW::Mechanize). Then when you change things you always know if something breaks, and what it is that breaks.
Then extract HTML into templates, and commonly used subs into modules. After that it's a piece of cake to switch to a framework.
In general, go step by step so that you always have a working application.
Extricate the HTML from the processing logic in the CGI script. Identify all code that affects the HTML output, as these are candidates for becoming template variables. Separate that into a HTML file, with the identified parts marked with template variables. Eventually you will be able to refactor the page such that all processing is done at the start of the code and the HTML template just called up at the end of all processing.
In this kind of situation, rewriting from scratch basically, the old code is useful for A) testing, and B) design details. Ideally you'd make a set of tests, for all the basic functionality that you want to replicate, or at least tests that parse the final result pages so you can see the new code is returning the same information for the same inputs.
Design details within the code might be useless, depending on how much the framework handles automatically. If you have a good set of tests, and a straightforward conversion works well, you're done. If the behavior of the new doesn't match the old, you probably need to dig deeper into the "why?" and that'll probably be something odd looking, that doesn't make sense at first glance.
One thing to remember to do first is, find out if anyone has made something similar in the framework you're using. You could save yourself a LOT of time and money.
Here is how I did it using Python instead of Perl, but that should not matter:
Separated out HTML and code into distinct files. I used a template engine for that.
Created functions from the code which rendered a template with a set of parameters.
Organized the functions (which I termed views, inspired by Django) in a sensible way. (Admin views, User views, etc.) The views all follow the same calling convention!
Refactored out the database and request stuff so that the views would only contain view specific code (read: Handling GET, POST requests, etc. but nothing low-level!). Relied heavily on existing libraries for that.
I am here at the moment. :-) The next obvious step is of course:
Write a dispatcher which maps URLs to your views. This will also lead to nicer URLs and nicer 404- and error handling of course.
One of the assumptions that frameworks make is that the urls map to the code. For example in a framework you'll often see the following:
http://app.com/docs/list
http://app.com/docs/view/123
Usually though the old CGI scripts don't work like that, you're more likely to have something like:
http://app.com/docs.cgi?action=view&id=123
To take advantage of the framework you may well need to change all the urls. Whether you can do this, and how you keep old links working, may well form a large part of your decision.
Also frameworks provide support for some sort of ORM (object relational mapper) which abstracts the database calls and lets you only deal with objects. For Catalyst this is usually DBIx::Class. You should evaluate what the cost of switching to this will be.
You'll probably find that you want to do a complete rewrite, with the old code as a reference platform. This may be much less work than you expect. However start with a few toy sites to get a feel for whichever framework/orm/template you decide to go with.