http://www.silverstripe.org/archive/show/1638
The above post seems like it's what I should do but I just need some help sorting this out in my head.
Firstly, I need to create a relationship between a page (Owner, for example) and a dataobject (Car). An owner can create many cars which are linked to that one owner. However, I have another page (Garage) which can create cars that are linked to every owner. If an owner does not want one of these cars they reject it. I was thinking the manymanydataobjectmanager would be good for that bit.
Each owner should only be able to see the cars that relate directly to them within the CMS, not other peoples cars, so I was using dataobjectmanager and assigning permissions to the page using groups.
The thing that is really making this awkward is that when it's all set up I need to output JSON which will consist of the cars the owners created and the cars they accepted from the garage, not the ones they rejected. I'm thinking I need another table like the linked table but with a status column perhaps?
To clarify, my question is how do I create this mess in a constructive SilverStripe way? Is the approach I was taking correct or is there a better way?
Many thanks in advance and please tell me if I've been unclear.
are you using silverstripe 3?
could you clarify what of the actions happen in the backend and what actions are possible for the user in the frontend?
maybe for your relations it could be better to use ModelAdmin:
http://doc.silverstripe.org/framework/en/reference/modeladmin
It gives you the opportunity to manage relations without the Sitetree/Pages Overhead. For example creating a Sitetree Element just to have an Owner is not the best way - except if you really need an Owner represented as a real Page. Owner could be also just a Dataobject instead.
Especially if you want to output just JSON in the end you are maybe completely independent of Sitetree/Pages... then you could write a custom controller with a routing rule and which gives you back just the data that you need:
http://doc.silverstripe.org/framework/en/topics/controller
regards,
Florian
Related
I'm making a firebase app where there's the concept of posts and authors.
I need to have a field called postedBy to give information about the post author. I'm currently confused on how to best implement this. Here's what I've thought about...
Store a postedBy field with the post author's ID as value. My issue with this is that I have to further send single requests for the user information, like name, profile picture etc.
I store a postedBy field with the exact clone of the author's data (name, profile URL, etc). My issue with this is what if the user changes their profile information? Do I have to loop through all the posts data to also ensure the changes?
What is the best way to solve an issue like this?
For your case, I would say that the best option would be probably to use only the ID as a value. This way, you can perform queries to return values using only the ID.
Using this approach should be the simplest and easiest way for you to create your application. Since the ID will be the point to connect your tables and to perform the queries, it should make your work easier.
In the below article, there is an example of a Blog application, that you can take a look and get some insights on how to configure your application as well - mainly about this part about author and post. :)
Learning Firebase: Creating a blog article object
Let me know if the information helped you!
Hello I have a technical question on how to implement multiple user types (not using FOS). I'll explain what I'm willing to do, I'd like some feedback on what can be done better or a suggestion on how to do it.
I'll have 4 entities
user
amateur
profesional
organisation
The default one that is implemented right now is user. To get things out of the way I'll user a second user provider for organisation as it will not be related to the previous ones.
I'm wondering how to do the User, Amateur, Profesional accounts.
They share most of the basic fields just have additional information to them. Most of them have the same permissions. Whats the best way to do It?
1) Adding a one to one extra entity to the User Class
I'll add a one to one AmateurInformation and ProInformation to the main User class. And determine the account type by a single accountType field.
2) Extending the Class with a child class?
I don't even know that something like this is possible. Also I'd like to make requests to the Repo that will return all User types.
Again I'm looking for suggestions on what to look into and how I can do this. I want to improve my knowledge while I'm at it :)
In my view two suggested solutions are viable (introducing a type field or using inheritance), really depends on your situation.
I would avoid using multiple independent classes, it will just complicate it.
If the relation to other database entries does not justify, it is not required to create separate classes, you can use the type field and maybe introduce specific roles (see getRoles() in UserInterface) for your different users.
If your user classes will have access to different things (relations to other entities), I would consider using a Single Table Inheritance with doctrine. With this solution you still can use one UserProvider and in code you can check the user object, and also, you can use custom roles to give permissions:
if ($user instanceOf Amateur)
I'm a beginner and it's the first time i hear this word outside the database world. So what does this means here:
In this case, yes. Generators are nice when there is a one-to-one
relationship between requests and responses, but when there is a
one-to-many fanout as seen here (or similar situations that arise with the
streaming_callbacks seen elsewhere in Tornado), I think it's cleaner to
just use callbacks than to try and fit everything into a generator.
Can you provide some application that uses one-to-one and one-to-many?
It's about database relationships, how an entry can be related to another or to many others.
For example, you have an User table and a Settings table.
One user is related to one settings entry. That's one to one.
Same think with table User and table articles:
One user wrote many articles. That's one to many.
You could try to read this:
http://net.tutsplus.com/tutorials/databases/sql-for-beginners-part-3-database-relationships/
I hope it helped.
Well, I know i'm going to be downvoted, but i think it's worth the shot.
I never worked with wordpress, and find it very displeasing to work with. A friend of mine asked me to implement a feature and i just don't have the time to understand it's inner works.
What i'm looking for is a plugin that let me have some sort of a tree, representing localization, kind of like:
Country
State
City
Person 1
Person 2
Person 3
and let me represent it with dependent select boxes that will list the people that belong to in the city, in the state, in the country i select?
Thanks for your help, and i'm sorry if this falls out the scope of SO
P.S.: yes, i have looked and looked in the wordpress plugin directory and haven't found anything.
Probably you will never find a plugin with such a feature.
This is a simple rule-based interface in a structure database.
I suggest you create a database structure parallel to wordpress with the characteristics necessary for the hierarchy shown in your example.
After this model database, you can use the the class wpdb() in wordpress to access this table and perform the query. In the link below there are instructions for this:
http://codex.wordpress.org/Class_Reference/wpdb
If you want to use the structure of the actual wordpress users, there are some plugins for listing users:
http://wordpress.org/plugins/simple-user-listing/
http://wordpress.org/plugins/user-list/
But user registration provided by wordpress can not provide detailed information about the user that you need.
Hope this helps.
I am developing a site that is saving non visible user data upon login (e.g. external ID on another site). We are going to create/save this data as soon as the account is created.
I could see us saving data using
the content profile module (already in use on our side)
the profile module
the data column in the user table
creating our own table
I feel like #1 is probably the most logical place, however creating a node within a module does not seem to be a trivial thing.
#3 feels like a typical way to solve this, but just having a bunch of serialized data in a catchall field does not feel like the best design.
Any suggestions?
IMO, each option has its pro's and con's, and you should be the one to make the final call, given that you are the only one to know what your project is about, what are the critical points of the project, what is the expected typical user pattern, what are the resources available, etc...
If I was totally free to chose, my personal favourites would be option #4, #1 and #5 (wait! #5? Yes: see below!). My guiding principles in making the choice would be:
Keep it clean
Keep it simple
Make it extensible
#1 - The content profile module
This would be a clean solution in that you would make easier for developer to maintain your code, as all the alteration to the user would pass through the same channel, and it would be easier to track down problems or add new functionality.
I do not find it particularly simple as it requires you to interact with the custom API of that module.
As for extensibility that depends from how well the content profile module API is designed. The temptation could be to simply use the tables done by said module for your purpose, bypassing the API's but that exposes you to the possibility that on a critical security update one day in which you are in a hurry the entire system will break down because the schema has changed...
#4 - Creating your own table
This would be a clean solution because you could design your table (and your module to do exactly what you need to), and you could create your own API to be used by other modules. On the other hand you would introduce yet another piece of code altering the registration process, and this might make it more difficult for devs to track problems and expand the system in a consistent way.
This would be very simple to implement code-wise. Also the DB design would benefit though: another thing to consider is that the tables would be very easy to inspect and query. Creating a new handler for views is dead easy in most of the cases: 4 out of 5 you simply use one of the prototype objects shipping with views.
This would be extremely easy to extend, of course. Once you created the module for one field, you could manage as many as you want by mostly copy/pasting the code for one field to another (or to inherit from the same ancestor if you go OOP).
I understand you are already knowledgeable about drupal, but if you need a pointer on how to do that, I gave some direction in this other answer.
#5 - Creating your own table and porting already existing fields there
That would essentailly be #4 minus the drawback of scattering functionality across various modules... Of course if you are already managing 200 fields the other way this is not a viable option, but if you are early into your design, you could consider this.
In my experience nearly every project that requires system integration (meaning: synchronising data for the same user in multiple systems) has custom needs for user registration, and I found this solution the one that suits my need best for two reasons:
I found I reuse a lot of the custom code I wrote from project to project.
It's the most flexible way to integrate data with the other system (in some case I even split data for the user in two custom tables managed by the same module: one that contains custom fields used by drupal only and one that contains the "non visible fields", as you call them. I find this very handy in a lot of scenarios, as it makes very easy to inspect and manipulate the data of the two systems separately.
HTH!
If you're already using the Content Profile module, then I'd really suggest continuing to use it and attach the field to it. You're saving the data when the account is created, and creating a node for the user at the same time isn't that hard. Really.
$node = new stdClass();
$node->title = $user->name; // what I'd use, or you can have node auto title handle the title for you. Up to you!
$node->field_hidden_field[0]['value'] = '$*#$f82hff';
$node->uid = $user->uid;
node_save($node);
Bob's your uncle!
I would go for option 3. Eventually even other modules will store the data in the database against a user. So you could directly save it yourself probably in a more efficient way than those modules.
Of course depending on the size of the data, you can take a call whether to add a new column in the users table or to create a new table for your data with the user's id as the foreign key.