In Sails.js you can easily create an api and this will provide you with action, rest and a shortcut api. This is wery clear from a lot of sources on the internet. This is also very practical when setting up a new app.
One thing that don't seems very clear is what to do when deploying the application to production. I can't think of anyone who would like /user to be open for anyone to see...
I don't really know how to handle this, there is many routes that one might not want to be open in production. I can think of the following ways to solve it:
close rest, actions and shortcuts in blueprints.js (which will remove all automatic apis), and then define them myself in routes.js.
Add policies for every route that I want no one to see (I don't even know all the routes that is automatically created so this seems risky).
Override all controller actions that should not be visible.
What is the right way to handle the routes that I don't want to have, when they are automatically created?
I don't like only your 3-rd method. I can suggest few methods:
Disable rest for all models in global blueprints configuration (config/blueprints.js) and enable it in needful models. Look overriding blueprints.
Yes, you can add policies to some blueprints. You can find list of all default blueprints ("routes that is automatically created") in blueprint-api reference.
Hope it helps you. Sorry for my english :)
Related
i would like to go for a step-by-step migration of my existing "serverside rendered" webapplications to a more "cientside rendered" approach.
my preferred starting-point would be to change the existing data-handling layer towards an ajax style approach using a rest http-api to handle put/post/get/delete requests.
so my question is...
is there an appropriate way to use the collection/model concept of backbone.js to my existing webapplication, without having to use routing/controller/views/templates?
i can add here, that i already have a working rest-httpapi using slimframework. and i would like to use backbone.js model/collections to fetch/save data. but html-rendering and event-binding should be out of backbone.js' responsibility for the moment.
thanks
i finally ended up with the "whole-stack" approach. after many hours of elab, there is no doubt to me, that an isolated usage of models without backbone-views and controllers is more painfull, than it helps.
thanks for all input.
I have an idea to add a edit-layer to website as a Plack middleware.
Explanation: let's say, we create a website, based on some framework and templates and CSS (requesting it like /some/page). Now we could create a middleware so that every request to pages starting with adm (like /adm/some/page) shows the same page, but adds a layer for content editing. So we could easily look and use the page as visitors do, but with double-click on block-level element we could modify or add content. So middleware should bind certain block-elements with certain events (double-click) and set handlers too (with some Javascript library).
For now it is just an idea and i have not seen such approach in any CMS. I am looking for hints and ideas and examples, how to start and implement such system. I hope, there is already done something like that.
You could do it, but I don't think you want to do this. My understanding is that Plack::Middleware's are supposed to be generic, and implementing a CMS as a plack middleware limits its re-usability, and its out of place, there is no inherent connection between a middleware and a CMS.
See these as examples Plack::Middleware::OAuth, Plack::Middleware::Debug, Plack::Middleware::iPhone, Plack::Middleware::Image::Scale, Plack::Middleware::HTMLMinify
It would be trivial to add a middleware filter to insert a form in your html based on /adm/ or /admin/ or whatever ... and mapping the url to the dispatch would highly depend on the underlying CMS model/view/controller framework, which is why frameworks such as Catalyst, Mojolicious and other already provide this feature
See http://advent.plackperl.org/2009/12/day-23-write-your-own-middleware.html
Basically, I think this is a job for a view/controller of your application, a plugin, not a wrapper for your application (middleware)
I know my explanation is lacking but hopefully you catch my drift
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.
I'm in the middle of converting an existing app built on top of zend framework to work as a plugin within wordpress as opposed to the standalone application it currently is.
I've never really used zend so I've had to learn about it in order to know where to begin. I must say that at first I didn't think much of zend, but it's funny because the more I understand how it works the more I keep questioning why I'd want to remove dependency when it's a clearly well thought out framework. Then I'm reminded that it's because of wordpress.
Now I already know there are WP plugins to make zend play nice with WP. In fact I'm aleady using a zend framework plugin just to get the app functional within the WP admin area which is allowing me to review code, modify code, refresh the browser, review changes, debug code, again and again.
Anyway, I really don't have a specific question but instead I'm looking for advice from any zend masters out there to offer advice on how to best go about a task like this one.... so any comments, advice, examples or suggestions would be super.
One area I'm a little stuck on is converting parts of zend->db calls to work as wpdb calls instead... specifically the zend->db->select.... not sure what to do with that one.
Also on how to handle all the URL routing with automatic calls to "whatverAction" within thier respective controllers files.
Any help would be great! Thanks
You're probably facing an uphill battle trying to get some of the more major components of ZF to work in harmony with Wordpress. It sounds like you've got a full MVC app that you're trying to integrate into a second app that has very different architecture.
You probably want to think about which components handle which responsibilities. Wordpress has it's own routing and controller system that revolves around posts, pages and 'The Loop'. This is entirely different from Zend's Action Controllers and routing system.
It's possible you could write a WP hook to evaluate every incoming request and decide if it should be handled by WP or a ZF controller. However, it is doubtful you would be able to replace WP's routing system outright with ZF's or vice versa.
Same idea, where Zend_Db is concerned. There's nothing stopping you from using Zend_Db to access Wordpress's database, but trying to somehow convert or adapt Zend_db calls into wpdb calls sounds painful. If you have a large model layer, you probably want to hang on to it, and find a way to translate data from those models into the posts/pages conventions that Wordpress uses.
Personally, I would use ZF to build a robust business layer that can be queried through an object model via a Wordpress plugin, and then rely on Wordpress to do the routing and handle the views.
Zend_DB_Select is simple SQL query (but created using objects) that can be used like any other query. Just turn it into string. Ex.:
mysql_query((string)$zendDbSelectObject);
I have the following bit of registration code:
Component.For<IPublishingService>().ImplementedBy<UseStoredProcedureToPrintService>(),
Component.For<IConfirmationDialog<AutomatedTransaction>>().ImplementedBy<ShipmentConfirmationDialog>().Named("ShipmentConfirmationDialog"),
Component.For<IConfirmationService<AutomatedTransaction>>().ImplementedBy<SingleTransactionConfirmation>().ServiceOverrides(
ServiceOverride.ForKey("shipmentDialog").Eq("ShipmentConfirmationDialog") ),
A requirement came down the line that in some instances the application is supposed to behave somewhat differently. Great I thought, this is exactly what I was using Castle Windsor for to begin with.
So I wrote my new components and I register them first. For example, I implement IPublishingService differently and register the new implementation first so that it is resolved over the default one above. However, a problem occurrs in the few cases where I had no choice but to use an id to wire up my service overrides. For example how do I redirect the ServiceOverride for ShipmentConfirmationDialog to use my new SpecialCaseShipmentConfirmationDialog implementation without modifying the bit of code above?
There are all sorts of mechanisms in castle windsor that I don't really understand like forwarding and ActAs that I'm hoping will provide a simple answer.
I'd keep it simple. If it's configurable, put it in the config (web.config / app.config) then just load the ID using ConfigurationManager.AppSettings["shipmentDialogToUse"];
Also remember that the fluent registration API is not the be-all and end-all of registration. XML still has its time and place where it's the right tool for the job.