I am pretty new to meteor and I am trying to make my first app which should have a profile page, later also with picture upload depending on user group.
As I understand I do not need a extra collection and subscription.
I am using useraccounts:bootstrap package with accounts-password. I added some custom fields to the profile (firstName, lastName, country).
Now I want to create a update or edit page. I could not find any resources which could been helpful.
Do I need to write all the logic for example testing the email address by my self? Or is this included by the package.
Or is it better to create a new collection for users with meteor-collection2?
Thanks
Witali
Collection2 will just attach its schema to the original user collection (if you proceed like suggested in collection2 readme).
As far as I know, I'm afraid that you will have to create some publications. Since editing user should be considered as "must-be secure", I would advise you to take a look at the existing packages. I'm quite a newbie to so I didn't look into the code of alanning roles package (which is, I've been told, excellent).
I used https://github.com/perak/user-roles. I think the code is good and clear.
The same guy, perak, made a meteor code generator which is still a work in progress, but looks very promising to me. Get one of his examples with user account and look at the client folder. You will have, when considering his user-roles package, all the code to do what you want.
ps: for email testing, look at his files in the client/lib folder but it is just a regex
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!
Could someone point me to documentation that shows how to create a record in a model with one to many relation via client side script.
Thanks in advance!
There are two ways of creating a new record.
1. Via a client-side script
You can do this by calling a createItem function from a widget. This link might help with that.
2. Via a server-side script
You can do this by directly creating a new record, assigning it to the relation of a model and then saving that model. This link might help with this method. By the way, it's easier to do this in a server-side script, as the guide itself says.
Since you just requested the link to official documentation, I've limited my answer to links only. Please feel free to ask if you need clarifications!
I'm trying to implement a signup flow in wordpress with the additional requirement that a user, to sign up, must use a secret activation code. Such code is valid only once, it's consumed after signup.
Many such codes are available (manually imported in DB is fine).
The use case is to let sign up only users who bought a (paper) book containing the secret activation code. In each book, the code will be different.
Before writing the whole thing manually, is there a plugin with a similar functionality? If not, what is the suggested implementation strategy?
There are a number of modules that already have this functionality, one that I've used before is simply "EasyInvitationCodes". There's also another one called "WP-Invites". If you use "invite" or "invitation" as your search keyword there are a few others available.
For EIC: https://wordpress.org/plugins/baw-invitation-codes/
For WP-Invites: https://wordpress.org/plugins/wp-invites/
Let me know if you've got any questions or if these aren't quite what you're after!
Currently i have not a code-problem, but i dont know which way would be better for me.
For our project, we have two kind of data which would be translatet for the view.
The part, which be coded in the source code like system messages (e.g. You are logged in, log out, etc.)
The second part is the database content like services, there can be added or deleted rows. And not for every entity would be a translation available.
Now i need to know, if i should save and get the translation from a translation table or is it better to transfer (via script) the translation into a services.xliff file
I would suggest to use XLIFF or GetText for the application (source: php, js).
Especially http://jmsyst.com/bundles/JMSTranslationBundle might be helpful.
The storage mechanism is less important, because of caching. So feel free to use either a DB or files as backend.
User created content is often managed via database. So you might use a common DoctrineExtension, like translateable. http://symfony.com/doc/current/cookbook/doctrine/common_extensions.html
https://github.com/stof/StofDoctrineExtensionsBundle/blob/master/Resources/doc/index.rst
I am looking for guidance regarding the best practice around the use of the Profile feature in ASP.NET.
How do you decide what should be kept in the built-in user Profile, or if you should create your own database table and add a column for the desired fields? For example, a user has a zip code, should I save the zip code in my own table, or should I add it to the web.config xml profile and access it via the user profile ASP.NET mechanism?
The pros/cons I can think of right now are that since I don't know the profile very well (it is a bit of a Matrix right now), I probably can do whatever I want if I go the table route (e.g., SQL to get all the users in the same zip code as the current user). I don't know if I can do the same if I use the ASP.NET profile.
Ive only built 2 applications that used the profile provider. Since then I have stayed away from using it. For both of the apps I used it to store information about the user such as their company name, address and phone number.
This worked fine until our client wanted to be able to find a user by one of these fields.
Searching involved looping through every users profile and comparing the information to the search criteria. As the user base grew the search time became unacceptable to our client. The only solution was to create a table to store the users information. Search speed was increased immensely.
I would recommend storing this type of information in its own table.
user profile is a nice clean framework for individual customization(AKA. Profile Properties). (e.g. iGoogle)
the problem of it is its not designed for query and not ideal for data sharing to public user.(you still would be able to do it, with low performance)
so, if you want to enhance the customized user experience, user profile would be a good way to go. otherwise, use your own class and table would be a much better solution.
In my experience its best to keep an the info in the profile to a bare minimum, only put the essentials in there that are directly needed for authentication. Other information such as addresses should be saved in your own database by your own application logic, this approach is more extensible and maintainable.
I think that depends on how many fields you need. To my knowledge, Profiles are essentially a long string that gets split at the given field sizes, which means that they do not scale very well if you have many fields and users.
On the other hand, they are built in, so it's an easy and standardized way, which means there is not a big learning curve and you can use it in future apps as well without needing to tweak it to a new table structure.
Rolling your own thing allows you to put it in a properly normalized database, which drastically improves performance, but you have to write pretty much all the profile managing code yourself.
Edit: Also, Profiles are not cached, so every access to a profile goes to the database first (it's then cached for that request, but the next request will get it from the database again)
If you're thinking about writing your own thing, maybe a custom Profile Provider gives you the best of both worlds - seamless integration, yet the custom stuff you want to do.
I think it is better off using it for supplementary data that is not critical to the user that is only normally important when that user is logging in anyway. Think data that would not break anything important if it was all wiped.
of course thats personal preference but others have raised some other important issues.
Also very useful considering it can be used for an unauthenticated user whose profile is maintained with an anonymous cookie.