Zend_Auth provides an API for authentication and includes concrete authentication adapters for common use case scenarios.
I started working with Zend Framework 2.0 beta1 and I noticed that it doesn't not include the Zend_Auth Module that was provided with Zend Framework 1. any ideas what replaces it?
or maybe it was just removed completely and I need to implement something of my own?
First (just to be clear): everything under library is called a component and not a module. Also, ZF2 is extremely beta so expect things will change often and no backwards compatibility is guaranteed.
Then, the Zend_Auth component has been renamed to Zend\Authentication. The first change is the underscore separation to namespaces, the second change is the renaming of Auth to Authentication. As far as I know, the features from Zend_Auth are all ported over to Zend\Authentication, the new component is also on GitHub.
Related
I need to find out how I can instruct Vite to replace references to local/relative modules at runtime. The use case here is the test runner mocha-vite-puppeteer, which uses Vite to run tests, but then stubbing of modules of course does not work when using Node machinery such as proxyquire or rewire.
So I basically need to either be tipped of some existing software that can help me in doing this, or some tips on how to create my own "vite-proxyquire" using import.meta and friends.
A normal use for temporarily stubbing out ./my-ugly-module might be that you want to avoid loading some sub-dependency that has some ugly transitive dependencies that suck the entire application tree into your little test, or you want to avoid loading a sub-dependency that has some ugly side effects on the global state.
Existing solutions
Modern Web, a refreshing "bundler- and frameworkless" approach to web development using standard tools, talk a bit about the issue around how the immutable nature of ES Modules prevent usual stubbing patterns. They present a solution in the form of Import Maps, which essentially would be similar to the alias config in Vite (Rollup really), mapping a path to a module to some other file. The problem with a static solution like this is that it would replace all imports of a given module, not just for a single test. Modern Web has a solution to this where they have chosen to use a custom html page for each such test. To make this less of a hassle with regards to running, they then have a custom test runner that handles dealing with all these extra test html files. Doing something like that could be one way of fixing it, but it would require developing quite a bit of middleware/plugin code IMHO to make it work transparently with Vite. Without any advanced tooling it would also introduce a lot of extra files that seems a bit of a downside compared to todays imperative mocking of dependencies with proxyquire, Jest or Test Double from inside of the test files.
I'm building simple gis system on geodjango.
The app displays a set of maps and I'm also attempting to provide a RESTFUL API for these maps.
I'm facing a decision whether to create a separate app for the API or to work inside my existing app.
The two apps are logically separate but they share the same models.
So what is considered better?
Although a case can be made for either of the approaches, I think keeping the APIs inside their associated apps would be a better one. Since the code in APIs is going to depend on the models, or other utility methods anyway, keeping APIs in the same app would lead to more cohesive code. Besides the very ideology behind Django apps is that they can be isolated and reused.
There used to be a similar case with storing the templates. In the initial days of Django, people used to prefer to store all the templates altogether in the same global folder (with subdirectories by the names of the app), however, in recent times even Django has started discouraging the said approach in the favour of storing templates in the respective app itself.
#hspandher's answer is very solid and will allow for most of your needs to be implemented.
There is though another approach which may be a bit more complicated to achieve but gives you all the space you may need for experimentation and reusability potential:
Separate everything:
Backend:
Isolate your API from its visualization (see frontend below) and make it completely autonomous and self-contained.
That can be achieved by separating your apps inside your Django project and expose the corresponding APIs which must be the only way for an external factor (ex. client, another app etc.) to "talk" with any one of your apps.
Frontend:
Assuming that you have your APIs exposed, you effectively separated the visualization from the logic and therefore you have many options on how to visualize your maps.
For example, you can now build a React app which can make requests to your API and visualize the responses by using any of those tools: leaflet.js, D3.js, or anything that you like really.
Summary:
The benefits of this separation are:
Separation of logic and implementation.
Better maintainability.
Many tool and technology options to use.
Reusability.
As a side note, you can read about 12 factor method and think about using it in your implementation.
My question is not about best practices for REST API URI design.
I've decided for myself, that i'm going to use the following approach:
https://theserver.com/api/v1/whatsoever
I'm much more curious about how to design the actual sourcecode in advance to easily extend the API with more versions.
Let's assume we've used a classic MVC-Framework for your favorite programming language. Our API works fine but we want to add & change functionality that is not backwards compatible. We did think about a nice URI design, but didn't think how our code should look in order to work nicely with different API versions. Crap.. What now?
Question: How should the source code for a versionable REST API look like?
Nice to have:
Not mixing up the different versions
Still best use of DRY
Don't reinvent the wheel over again
will be extended
Possible answers i can think of:
Same project - different Namespaces & Subfolders
Namespace: namespace App\Http\Controllers\v1\Users;
Folder: {root_folder}\app\Http\Controllers\v1\Users\UserLoginController.php
Different projects
Point https://theserver.com/api/v1/whatsoever to project 1
and https://theserver.com/api/v2/whatsoever to project 2
Here is my logic: - First of all we need to answer to the question "Why we need versioning?"
- If we can extend our API in way it is backward compatible, in that case we don't need versioning (All applications and services are going to use the same API and no changes are needed).
- If we can not can not provide backward compatible API in that case we need to introduce next version of our API. This will allow all applications and services to migrate smoothly to new version while to old one is working. After a time period (one year), first version can be obsoleted and stopped.
So based on the answer above I would keep API versions in separate branches in my repository. One codebase, multiple branches for each version. First branch corresponds to v1 which is stable and receives only fixes. No active development here. Second branch corresponds to v2 which has all new features.
For all the things I love about Grails I do have one small issue and this isn't really even a Grails specific problem. GSP changes require redeployments of the entire web application. I'm not talking about adding new dynamic data or major changes. These generally requires server side changes as well anyway.
But I'm talking about smaller changes like flipping the position of a couple of elements or modifying some simple static text on the page. So my question is, what are some patterns used or plugins, etc that allow minor changes to GSP's without redeploying the entire application? How can I make Grails template/GSP's more like templates and less requiring compiling?
I'm also possibly looking for something more designer friendly.
grails.gsp.view.dir, I think.
A trick to remember: add trailing slash and remember that grails-app/views will be added to it.
There is a Grails Plugin for using FreeMarker templates as views (I have not used this plugin myself). It is not listed as SpringSource supported, but I think the author is one the core grails devs and the plugin is based on a relatively new version of FreeMarker.
I need to use a rails app from C++. I say login in the title because that's one of my options.
As far as I see it, I either need to do the standard login, and keep track of a session or something in the C++ code, or use an API token of sorts, and just pass that on every URL and never actually create a session on the rails side (which uses restful_authentication).
Are those my only two options? Are there any nice C++ libs to deal with RESTful services or specifically rails?
The C++ side of things is on Windows btw.
It may be lower-level than you're looking for, but I believe you should be able to accomplish this sort of thing with libcurl (and, potentially, libxml if you need an HTML or XML parser to handle return values).