Cakephp Search Plugin from CakeDC - search

Has anyone incorporated the Seach plugin from CakeDC?
I am a confused as in how it has to be used. I am creating a Seach Controller and trying to search all models from there.
In the Wiki, it states that I should create a $filterArgs variable on my models. Should I have public $filterArgs in every model or should only at one place?
If there is a tutorial can someone point me to it?

Should be in each model. The controller, which generally uses only one model, then uses it. I've had nothing but trouble trying to make one controller handle multiple models, apart from using one model and related data.

Related

Creating through model relation not creating relation

I'm trying to create a relation between models using Loopback, but for some reason it seems like it is not saving my relations at all. But it could also be that I'm doing something wrong.
The relation looks like this:
So a User can be in 0 or more Pools. When they are in a Pool they are a PoolMember. And a PoolMember can add Predictions.
Right now I'm trying to create a relation between a User and Pools.
I did a slc loopback:relation and then selected User as from model. Then selected hasMany and picked Pool from the list. Then it asked if the relation has a throughModel. I selected Yes and then picked PoolMember from the list.
I'd then expect that either PoolMember.json or Pool.json has a relation defined in it. But they seem to remain unchanged.
I even deleted my project and redid everything. But have the same problem.
So am I doing something wrong here? Or is this a bug in Loopback?
If you are using built-in models ("User" in your case), you should extend built-in model and then create relation or any other modification.
Currently you cannot modify a built-in model's required properties. If you need to do this, then create your own custom model as a replacement instead.
By default, a LoopBack application has a built-in User model defined by user.json (this file is part of the LoopBack framework. Don't modify it; rather, follow the procedure in Extending built-in models).
See Customizing models and Managing users

How to associat a model to itself in a Many to Many way using Sails.js/Waterline?

I have a sails.js project and I need a Model to be connected to itself as many to many, is it possible?
Yes(ish)
You can create a second model (for the purpose of the association). The second model would reference the same table as the first model and then you just create an association the way you normally would.

Core data mapping model with new (non-optional) relationship

My original data model has an entity "Game". I have now updated the model to include an entity, "Match", which can refer to multiple games. I wish to add a Match to all of my old Games, and ideally this would be a non-optional relationship.
Currently I am setting Match to be optional, and simply adding a Match to every old Game in application:didFinishLaunching after the model has been updated. This works, but I'm wondering if this is really the best way to do it.
I have tried to follow the tutorial here, but I am getting stuck on the part with "StepOneEntityMigrationPolicy.m". I have created an NSEntityMigrationPolicy subclass and set it in the mapping model. I've tried overriding both createDestinationInstancesForSourceInstance and createRelationshipsForDestinationInstance:, but neither get called.
Is this perhaps because my Source and Destination are both the same (GameToGame)? Also, is there any benefit to doing this via the mapping model rather than as I am doing it now?
I think the simplest and most pragmatic way is what you are doing now, i.e. inserting the necessary new entities "manually" after an update. This is a common way to populate orphaned entities after a model version upgrade and perfectly fine.

How can domain model classes (generated by EF 5 Database First) support custom logic when a database update replaces the code?

Please pardon the long-winded title to this post.
Basically, I have an entity model that was generated by Entity Framework 5 using the Database First method. Now I would like to develop those POCO entity classes by adding validation logic and anything else I might need to go in there. The problem... (and this is so glaring I can't believe I couldn't find any answer to this on the web)... is that any time my database schema should change and I use the "Update Model from Database" command from my model diagram, the POCO classes are re-generated and all custom code is lost.
As far as I understand, the "domain model" layer in an MVVM application is largely comprised of what EF generates (in database first approach), plus validation (perhaps implementing the IDataErrorInfo. But if this was the right way to do it, why would this be wiped away when using database-first model updates?
What am I missing?
Thanks
You should use partial classes. That is why they are there.
If you want to know the basics see this short example:
http://www.dotnetperls.com/partial
Here is more on partial classes from the msdn:
http://msdn.microsoft.com/en-us/library/vstudio/wa80x488.aspx
If you want to use your own namespaces in the genarted code, you can refer to this SO question:
Entity Framework 5 partial classes not working

Subsonic: Bring me to tiers

This is an embarrassingly basic n-tier question.
I've created a DAL project in VS2008 with subsonic. It's got a widget class, a widgetcollection class, and a widgetcontroller class.
I've created my Business logic project (no I can't put it in the same tier) that references it. Using certain business criteria, it selects a collection of widgets in a function that returns a widgetcollection.
My question is: how does my GUI layer bind the collection to a grid? I know that the widgetcollection is a valid datasource for a datagrid, but how does the GUI layer know what a widget and widgetcollection are? Surely I don't have to reference the DAL from the GUI, that negates the whole point.
Firstly, I dont think this is an embarrasingly basic n-tier question.
It is a very interesting subject and one I attempted to stimulate discussion for in the old Subsonic Forums.
I share your reluctance to expose my GUI layer to the DAL.
My GUI layer only talks to BLL using the vocabulary and topics of my own Entity Model and only returns my own entities or lists or in some cases Data Tables.
My BLL only talks to a MAPping layer which maps Fetches,Saves etc to the appropriate DAL CRUD methods and converts the returned Subsonic types to my Entity types.
In doing this I was suprised at how much of Subsonic I had to duplicate and at times I felt I was going down the wrong road, I am feeling more comfortable with it now, though it still needs refactoring and refining.
For example, finding a flexible, generic means of indicating to my BLL which row(s) I wanted returned in a fetch was a challenge I hadn't expected and I finished up writing a generic queryClass with fluent interface which looks a lot like a Subsonic Select.
FWIW, I think you are headed down the right track, I guess what you have to do though is decide how you want to define those Subsonic types to your GUI.
Rob has an interesting discussion you may be interested in.
(using SubSonic 2.x) In my BLL classes I have a property which gives an object reference to the relevant DAL class. My UI form has a reference to the BLL class, so from the form I can address the DAL properties and methods via .BLL.DAL.xxxx
FWIW, I have never managed to successfully bind a SubSonic collection to a DataGridView. As alternatives, I sometimes use the collections .ToTable() method to create a DataTable and then bind to that, or alternatively I manually bind using .AddRow()
Look at the documentation for IBindingList Interface in MSDN, it has a pretty good sample.
Create, for example, a CustomersList class in your model that uses a Customer class in your BLL. Bind the grid to an instance of the CustomersList class. The presentation layer has no knowledge of the subsonic table classes.
You probably need to use an Interface. You can easily create an interface based off of the Widget in your Dal(right click on the class and create an Interface from the class). Next take the Interface and add it to your Business Logic Layer or a seperate project just for interfaces. Once you have done that you can add a reference to the Interface both in the DAL and in the GUI. This can also help if you ever change your data storage from a Database to XML etc. etc.

Resources