I have an app built on Model-Glue: Unity that contains some search forms. I need to trim leading and trailing spaces from search strings before using them to query the database. I'm also keeping the search terms in a bean that a user can save and re-use.
My problem is that I am unsure where to perform that trim(). The bean seems to be the wrong place for it, as I'm keeping the bean simple (no logic). Normally I would take care of that when updating the bean, but I'm using MakeEventBean to keep things simple. Re-touching all of the data in the Service layer seems an unnecessary layer of overhead. And, lastly, doing it in the datalayer with the actual SQL query doesn't seem right either. It'll work, but the information in my search bean will still be wrong.
What have you done in such cases?
Disclaimer: I'm not a MG user, so I'm not sure if this will be good and possible approach. Just want to share the idea.
In case of Transfer ORM beans I do such specific things in decorators which extend auto-generated beans.
For example, I can easily override setter setSearchPhrase(phrase), where trim the argument value and invoke original method.
I ended up making my Beans a little smarter than they were. Rather than monkey with every single setThing() method, I added a trimAll() method simple applied a trim() to each of the private properties in the Bean.
Related
How would one use Django DestroyAPIView and DetailAPIView and still maintain generally accepted practices of RESTfulness?
If I understand REST correctly it should work as follow (only one example)
/api/game/222
then 1 view class(generics.DetailAPIView) or method, in Django would be created to handle the call
In a REST world, I believe we would use a generic API class to handle the
methods (get,...)
But if I wanted to use the class(generics.DestroyAPIView) to handle the calls to delete a game.
then I would have to use
/api/game/delete/222
to send the request to the correct view.
It seems to me this is not consistent with RESTFULness.
for the delete method of the HTTP should be used to send the delete request and use the same pattern matching /apt/game/222 to delete the game. It's redundant.
Question: Am I missing something?
In summary
option 1:
/api/game/delete/222 (DestroyAPIView)
/api/game/detail/222 (DetailAPIView)
option 2
/api/game/222 (RetrieveDestroyAPIView)
I guess either way works, and as long as it's clear and consistent as stated below. There is no "right" way.
I not sure 'RESTFULness' affect what you are asking here. It is perfectly fine to have different matching pattern as long as it make sense.
In the example given, usually we do not have /api/game/222 as a generics.ListCreateAPIView. This is because List return a list of all game, we do not pass a id in. Create is trying to create a new Game. You do not have id yet because it is not in database, therefore both of the matching pattern should usually be /api/game/ instead.
/api/game/222 - such pattern, we usually use for generics.RetrieveUpdateDestroyAPIView because with a given id in url, we can get the correct Game object to either retrieve, update or delete it.
Regarding the Restful API, the answers in this stack overflow question explain more about 'Restfulness'.
I need a way for ember router to route to a recursive path.
For Example:
/:module
/:module/:submodule
/:module/:submodule/:submodule
/:module/:submodule/:submodule/...
Can this be done with Embers router, and if so, how?
I've been looking for examples, tearing apart the source, and I've pretty much come to the conclusion, it's not possible.
In a previous question, someone had pointed me to a way to get the url manually and split it, but I'm stuck at creating the state for the router to resolve to.
As of now, in my project, I currently just use the Ember.HashLocation to setup my own state manager.
The reason for the need of this, is because the module definitions are stored in a database, and at any given point a submodule of a submodule, recursively, could be added. So I'm trying to make the Application Engine handle the change.
Do your submodules in the database not have unique IDs? It seems to me that rather than representing your hierarchy in the path, you should just go straight to the appropriate module or submodule. Of course the hierarchy is still in your data model, but it shouldn't have to be represented in your routing scheme. Just use:
/module/:moduleId
/submodule/:submoduleId
And don't encode the hierarchy in the routes. I understand it might be natural to do so, but there's probably not a technical reason to.
If your submodules don't have unique ids, it's maybe a little tougher...you could build a unique ID by concatenating the ancestor ids together (say, with underscores), which is similar to splitting the URL, but a little cleaner probably. I will say that Ember/Ember Data doesn't seem to be too easy to use with entities with composite keys--if everything has a simple numeric key everything becomes easier (anyone want to argue with me on this, please explain to me how!).
DO you mean like this:
App.Router.map(function(match) {
match('/posts').to('blogPosts');
match('/posts/:blog_post_id').to('showBlogPost');
});
I've found myself unsatisfied with Django's ability to render JSON data. If I use built in serializes then database foreign key relationships are not included in the data (only the keys). Also, it seems to be impossible to include custom data in the json feed that isn't part of the model being serialized.
As a test I implemented a template that rendered some JSON for the resultset of a particular model. I was able to include/exclude whatever parts of the model I wanted and was able to include custom data as well.
The test seemed to work well and wasn't slower than the recommended serialization methods.
Are there any pitfalls to this using this method of serialization?
While it's hard to say definitively whether this method has any pitfalls, it's the method we use in production as you control everything that is serialized, even if the underlying model is changed. We've been running a high traffic application in for almost two years using this method.
Hope this helps.
One problem might be escaping metacharacters like ". Django's template system automatically escapes dangerous characters, but it's set up to do that for HTML. You should look up exactly what the template escaping does, and compare that to what's dangerous in JSON. Otherwise, you could cause XSS problems.
You could think about constructing a data structure of dicts and lists, and then running a JSON serializer on that, rather than directly on your database model.
I don't understand why you see the choice as being either 'use Django serializers' or 'write JSON in templates'. The middle way, which to my mind is much more robust and fits your use case well, is to build up your data as Python lists/dictionaries and then simply use simplejson.dumps() to convert it to a JSON string.
We use this method to get custom JSON format consumed by datatables.net
It was the easiest method we find to accomplish this task and it looks very fine with no problems so far.
You can find details here: http://datatables.net/development/server-side/django
So far, generating JSON from templates, we've run into the need to escape newlines. Looking at doing simplejson.dumps() next.
I'm new to the Repository Pattern and after doing a lot of reading on the web I have a rough understanding of what is going on, but there seems to be a conflict of ideas.
One is what the IRepository should return.
I would like to deal in ONLY Pocos so I would have an IRepository implementation for every aggregate root, like so:
public class OrangeRepository: IOrangeRepository
{
public Orange GetOrange(IOrangeCriteria criteria);
}
where IOrangeCriteria takes a number of arguments specific to finding an Orange.
The other thing I have is a number of data back-ends - this is why I got into this pattern in the first place. I imagine I will have an implementation for each, e.g
OrangeRepositoryOracle, OrangeRepositorySQL, OrangeRepositoryMock etc
I would like to keep it open so that I could use EF or NHibernate - again if my IOrangeRepository deals in POCOs then I would encapsulate this within the Repository itself, by implementing a OrangeRepositoryNHibernate etc.
Am I on the right lines?
Thanks
EDIT: Thanks for the feedback, I don't have anyone else to bounce these ideas off at the moment so it is appreciated!
Yes, your version is the safest / most compatible one. You can still use it with about any resources, not only data access ones, but with web services, files, whatever.
Note that with the IQueryable version you still get to work based on your POCOs classes, but you are tied to the IQueryable. Also consider that you could be having code that uses the IQueryable and then turns out it you hit a case where one of the repository's ORM doesn't handle it well.
I use the same pattern as you do. I like it a lot. You can get your data from any resources.
But the advantage of using IQuerable is that you do not have to code your own criteria API like the OrangeCriteria.
When NHibernate gets full Linq support then I may switch to the IQueryable.
Then you get
public class OrangeRepository: IOrangeRepository {
public IQueryable<Orange> GetOranges();
}
Is it possible to have a fixture change between test methods? If so, how can I do this?
My syntax for this problem :
In the cakephp framework i am building tests for a behavior that is configured by adding fields to the table. This is intended to work in the same way that adding the "created"
and "modified" fields will auto-populate these fields on save.
To test this I could create dozens of fixtures/model combos to test the different setups, but it would be a hundred times better, faster and easier to just have the fixture change "shape" between test methods.
If you are not familiar with the CakePHP framework, you can maybe still help me as it uses SimpleTest
Edit: rephrased question to be more general
I'm not familiar specifically with CakePHP, but this kind of thing seems to happen anywhere with fixtures.
There is no built in way in rails at least for this to happen, and I imagine not in cakePHP or anywhere else either because the whole idea of a fixture, is that it is fixed
There are 2 'decent' workarounds I'm aware of
Write a changefixture method, and just before you do your asserts/etc, run it with the parameters of what to change. It should go and update the database or whatever needs to be done.
Don't use fixtures at all, and use some kind of object factory or object generator to create your objects each time
This is not an answer to my quetion, but a solution to my issue example.
Instead of using multiple fixtures or changing the fixtures, I edit the Model::_schema arrays by removing the fields that I wanted to test without. This has the effect that the model acts as if the fields was not there, but I am unsure if this is a 100% test. I do not think it is for all cases, but it works for my example.