I need to create a pretty complex website for my class and before I started, I wanted to get some input from more experienced coders if I'm on the right track.
Basically, when I go to the url: I get a simple login page, when a user logs in - he can view his profile and make schedules / save etc...
I read a bit online and this is how I decided to proceed (please let me know if there is a simpler way or an already-made code for these):
1 . Access phpmyAdmin - create db
2 . Create a php function to access the db (add users etc...)
3 . use a login form with a php function on the main page and authenticate user/pass by accessing the db
4 . Use cookies to keep user logged in.
I also need to keep several lists for each user like:
classes = (comp232 , comp348 , comp352.....)
Which is the best way to do this for each user:
DB, txt file, List, Arrays?
The answer is 'depends'. However, when you had mentioned that you want to develop a 'complex website', it deserves to have Database roundtrip :) whereas all the other options you had mentioned would be simple enough for a stand alone application.
To answer your other main question, yes, there are already built in solutions which you can make use of, if you don't want to write the application on your own. However, you may need to evaluate thoroughly whether it fits your bill, else you may end up customising the application which is more or less half writing of the application by yourself.
If you want to write the application by your own, the PHP has got a built in APIs to achieve whatever you had mentioned. We have a great set of forums to get assistance wherever we are stuck.
Related
I've been searching around for a while on this, but as of yet haven't found anyone else trying it. So I'm asking for feedback and critique - both on if this seems reasonable, and if there's a better established pattern for it.
Basically, I want to be able to easily publish a "demo" version of a react/redux app. My specific example is an app I built but that is only useable with our internal database with user information. I can't show that anywhere, because we don't want the information to escape out into the world.
Since all of the model interactions are routed through redux, it occurred to me that I could drop in a new set of actions based upon the URL.
Say the user goes to myawesomeapp.com - they're given the full app, login prompts, security, access to the database.
But an outside party could go to demo.myawesomeapp.com (for example), and get an app that is functionally the same but is wired up to dummy data that isn't saved.
The general pattern that I have would be this:
Vaguely, in actions/index.js
export * from './common_actions';
if (location.href.match(/demo\.myawesomeapp\.com/)) {
export * from './demo_actions';
}
else {
export * from './actions';
}
I don't really like that - it feels brittle and like a hack. But it works! Registered users can use the actual app, and demo users can try it out in a sandbox.
Judicious use of exported constants and values also allow peppering of other flags and data - overlays of text to walk through things, links to sign up for the actual app, etc.
I love this as a concept - with just a few new redux actions, you get a fully sandboxed app to show off with no worry of cross contamination. It's much easier than trying to sanitize all the endpoints.
And even if an action wasn't properly isolated in this manner, the worst that would happen is that they'd get an access denied error from the actual backend since they're not logged in.
But to the world, my questions are -
1) Does this seem like a reasonable thing to do or are there gotchas I'm not considering it?
2) Does this seem like a reasonable way to implement it, or is there a better approach I haven't considered?
I don't like this solution, if i understood you correctly this solution will duplicate your code, which is never a good idea, you'll have to change two different code bases with every little change, needless to say it will duplicate your work, why not just point the demo app to a different database ? or better yet(and it's also industry standard) create a "time trial" role for your users so they can test your app and if they like it, they already have an user account.
Thanks in advance for any help offered and patience for my current web-coding experience.
Background:
I'm currently attempting to develop an web based application for my family's business. There is a current version of this system I have developed in C#, however I want to get the system web-based and in the process learn cakephp and the MVC pattern.
Current problem:
I'm currently stuck in a controller that's supposed to take care of a PurchaseTicket. This ticket will have an associated customer, line items, totals etc. I've been trying to develop a basic 'add()' function to the controller however I'm having trouble with the following:
I'm creating a view with everything on it: a button for searching customer, a button to add line items, and a save button. Since I'm used to developing desktop applications, I'm thinking that I might be trying to transfer the same logic to web-based. Is this something that would be recommended or do'able?
I'm running into basic problems like 'searching customer'. From the New Ticket page I'm redirecting to the customer controller, searching and then putting result in session variable or posting it back, but as I continue my process with the rest of the required information, I'm ending up with a bit of "spaghetti" code. Should I do a multi part form? If I do I break the visual design of the application.
Right now I ended up instantiating my PurchaseTicket model and putting it in a session variable. I did this to save intermediate data however I'm not sure if instantiating a Model is conforming to cakephp standards or MVC pattern.
I apologize for the length, this is my first post as a member.
Thanks!
Welcome to Stack Overflow!
So it sounds like there's a few questions, all with pretty open-ended answers. I don't know if this will end up an answer as such, but it's more information than I could put in a comment, so here I go:
First and foremost, if you haven't already, I'd recommend doing the CakePHP Blog Tutorial to get familiar with Cake, before diving straight into a conversion of your existing desktop app.
Second, get familiar with CakePHP's bake console. It will save you a LOT of time if you use it to get started on the web version of your app.
I can't stress how important it is to get a decent grasp of MVC and CakePHP on a small project before trying to tackle something substantial.
Third, the UI for web apps is definitely different to desktop apps. In the case of CakePHP, nothing is 'running' permanently on the server. The entire CakePHP framework gets instantiated, and dies, with every single page request to the server. That can be a tricky concept when transitioning from desktop apps, where everything is stored in memory, and instances of objects can exist for as long as you want them to. With desktop apps, it's easier to have a user go and do another task (like searching for a customer), and then send the result back to the calling object, the instance of which will still exist. As you've found out, if you try and mimic this functionality in a web app by storing too much information in sessions, you'll quickly end up with spaghetti code.
You can use AJAX (google it if you don't already know about it) to update parts of a page only, and get a more streamlined UI, which it sounds like something you'll be needing to do. To get a general idea of the possibilities, you might want to take a look at Bamboo Invoice. It's not built with CakePHP, but it's built with CodeIgniter, which is another open source PHP MVC framework. It sounds like Bamboo Invoice has quite a few similar functionalities to what you're describing (an Invoice has line items, totals, a customer, etc), so it might help you to get an idea of how you should structure your interface - and if you want to dig into the source code, how you can achieve some of the things you want to do.
Bamboo Invoice uses Ajax to give the app a feel of 'one view with everything on it', which it sounds like you want.
Fourth, regarding the specific case of your Customer Search situation, storing stuff in a session variable probably isn't the way to go. You may well want to use an autocomplete field, which sends an Ajax request to server after each time a character is entered in the field, and displays the list list of suggestions / matching customers that the server sends back. See an example here: http://jqueryui.com/autocomplete/. Implementing an autocomplete isn't totally straight forward, but there should be plenty of examples and tutorials all over the web.
Lastly, I obviously don't know what your business does, but have you looked into existing software that might work for you, before building your own? There's a lot of great, flexible web-based solutions, at very reasonable prices, for a LOT of the common tasks that businesses have. There might be something that gives you great results for much less time and money than it costs to build your own solution.
Either way, good luck, and enjoy CakePHP!
I am building an GAE app that allows users to share documents over different contexts. Nothing too fancy.
I want to use Gdata in such a way that it is the app that owns the documents, and not the users. This way, I shouldn't need any kind of tokens --one would think.
This is the main idea:
App user creates doc --> App creates doc and owns it --> user can RUD & share the doc
Is there any recommended way to authenticate using just a hard coded user & password?
The ClientLogin, up to now, seems to be the way to go.
http://code.google.com/apis/gdata/docs/auth/clientlogin.html
But I still have some doubts about the following:
Am I putting myself in a scenario of possible restrictions over other alternatives?
Is really ClientLogin the best way to go?
Could really use advice from others' experience here. Procrastination is killing me.
Cheers,
A.
If this is a personal project, and you've only got a very small group of users, the design might be OK.
One really good reason to use OAuth is that you won't need to store the account password somewhere. Instead you'll be able to implement a simple 'setup' process to get and store an access token. OAuth is also nice since you'll be able to restrict the access scope.
However, I must say, I find your question very vague -- so more specific answers are difficult.
I have a forum with >400 registered users. It's powered by vBulletin-4.0.4. I want to build up several websites with kohana-3.1, but keep existing forum users too. I will use seperate databases for each application (I want to keep apps as independent as possible).
So my solution is:
step 1. create special app users.mydomain.com where each user can register and update their details (birthdate/email/password). This app will catch all changes and write them to forum database and application databases.
step 2. modify default auth module to handle forum authentication. vBulletin uses algorithm: $hash=MD5(MD5($password)+$salt) for pass hashing.
Am I in the right direction? Is it OK?
Someone has already done this: Kohana vBulletin Bridge. You will need to contact the author of the module as the source code is no longer online. It wont be too difficult to upgrade it to 3 if you get it.
I haven't used vBulletin so I can't give you much advice on the subject, but you're right about the hashing algorithm. You'll also need to make sure your session is read and written as they are in vBulletin.
A quick search of vBulletin SSO to get you started.
I'm asking your opinions about my next project..
I'm planning to make website which offers services where all users would be have own subdomain (user.mydomain.com) and own website.
First I was thinking to really make real subdomain, generating automatically website code into their folder, creating own database etc..
Question #1: When I need some information from all subdomains databases in my main page (mydomain.com), how can I fetch those?
Would it be better way just use one database and dynamic code what all users are using but then re-write address like it would be subdomain (mydomain.com?user=myuser -> myuser.mydomain.com)
If someone have experience with something like what I was planning, would be nice to have tips and tricks do it right! :)
Thanks!
It will be alot of less code to maintain in you have one common codebase for all users, that just reads the domain name and uses that information.
Imagine that you discover an error in the code that was generated for one of the subdomains.
Either you would have one place to correct, or you would have 1 place + the number of users to correct.
You'll probably want all of the subdomains to point to the same codebase and treat the subdomain as an argument that is pulled out and identifies which instance of this application it is. You'll need a table in your db that will store information about each instance and then user accounts, user data, etc will all be tied back to a specific instance.