in reply to Re^2: Hide Data based on account
in thread Hide Data based on account

If you don't want to use database storage (it is something very good to learn and use), you can also just create an account table. Something you can create with a spreadsheet, written as a CSV file, and then read it in as a logic table. Then, using any structure you can follow, you can test your conditionals for viewing options.

Doing it this way is simple, but not very robust. Even so,with the proper strategy, you can add and modify accounts from that same spreadsheet. Obviously, this will get very cumbersome if your logic table gets very large, and you will have to eventually add management tools to ease this work. Also, adding accounts by hand is not very automatic.

Adding a logic tree is reasonable too. By filtering by division, you might avoid a bunch of other tests. How you lay out the data will be impacted by this additional complexity. Having your data field contain sub-fields is not very CVS friendly, but it can be done with careful mapping. Again, this type of granularity is something that databases provide.

Replies are listed 'Best First'.
Re^4: Hide Data based on account
by grashoper (Monk) on Sep 19, 2007 at 17:42 UTC
    I am using sql, not sure how to add what I need to it though I am thinking at this point just a products lookup table (list) and adding a product id to exisiting alerts table will give me flexibility enough to move forward, can you recommend any good resources on sql, seems like most sites about sql are either too basic or too advanced can't find a nice middle of the road introductory site.

      Your best resource is the DBI module. With it, you can do SQL queries at your current level of understanding and do the rest in Perl. As your knowledge of SQL gets more sophisticated, you can upgrade your code to take advantage of the database engine capabilities.

      I've always found it easier to learn by example too. MySQL Cookbook may be the middle ground you seek.

Re^4: Hide Data based on account
by grashoper (Monk) on Oct 02, 2007 at 10:11 UTC
    Actually it is already using sql server and populating user information for authentication from there. The grouping by permissions is also there but needs to be expanded upon. For the time being my task is to change the content displayed based upon the referrer, which is already being captured, for the new product my pass through preauthentication script is not currently working, my guess is that they are not using md5 authentication which the other division of the company is using, however I could be wrong about that it could just be located elsewhere in the other products userinformation - database, as a short term workaround I have it response->redirecting to a static page, which is context sensitive based upon a topic being returned by the query string all that currently displays is the relevant portion of the help file. Users can also login to the site with their user information and that does work but doesn't map to my static page, its a generated page, using xml and xslt to display the content dependent on what xml files are present for that specific site, there are 55 or so old sites that work just fine this way, I need to change the content so some of the "generic" content for the old 55 sites don't come through in the "new" sites. I hope that made sense. I am thinking perhaps a Switch structure would work well here but I am not certain where I should put this switch, it needs to make the decision before it starts creating the page, problem is the original author was using many does it go in all the include files...and branch off to other subs instead of the originals?

      It is clear you need to define some form of permission map and decide how to implement it. The problem is; what strategy to use.

      Ask ten developers and get ten answers, most of which won't apply to your specific situation. It really boils down to what you are willing and capable of doing with the resources you have. If you find that the components you have don't supply enough information to make a decision in every case, then you are going to have to develop that yourself. If you do have all the information, but don't have a strategy to implement the decisions, START SIMPLE.

      It is not a sin to have your entire logic tied to an IF logic tree, especially initially. Don't over-complicate your solution just because you are looking for elegance. If elegance comes to you, and it provides the solution you are looking for, well... excellent!

      A strategy that is useful is compartmentalizing. If you have this THING that needs to only show when a set of values align. Go for it. Make it a TRUE/FALSE subroutine, and then move on. Solve each situation similarly. You are bound to find some overlap. When it is natural, combine or re-use. As you go along, some patterns may emerge that speaks to you of a clear and elegant solution to large portions of your already written logic. Good for you.

      The sin will be worrying about optimizations and elegance too early. Don't do that. It will drive you insane. Start simply, make sure it completely works for the situation it was designed for and move on. If you write readable code, comment where necessary, and don't sweat the beauty of it all, you may find you have created a completely suitable solution after all.