0

I am using Server Side JavaScript - yes, I am actually using Server Side JavaScript. To complexify things even more, I use Oracle as a backend database (10g). With some crazy XSLT and mutant-like HTML generation, I can build really fancy web forms - yes, I am aware of Rails and other likewise frameworks and I choose the path of horror instead. I have no JQuery or other fancy framework at my disposal, just plain ol' JavaScript that should be supported by the underlying engine called Mozilla Rhino. Yes, it is insane and I love it.

So, I have a bunch of tables at my disposal and some of them are filled with associative keys that link to values. As I am a people pleaser, I want to add some nifty user-preference driven solutions.

My users have all an unique user_id and this user_id is available during the entire session.

My initial idea is to have a user preference table, where I have "three" columns: user_id, feature and pref_string. Using a delimiter, such as : or - (haven't thought about a suitable one yet), I could like store a bunch of preferences as a list and store its elements inside an array using the .split-method (similar like the PHP-explode function). The feature column could be like the table name or some identifier for the "feature" i want to link preferences too. I hate hardcoding objects, especially as I want to be able to back these up and reuse this functionality application-wide. Of course I would love better ideas, just keep in mind I cannot just add a library that easily.

These preferences could be like "joined" to the table, so I can query it and use its values.

I hope it doesn't sounds too complex, because well.. its basically something really simple I need.

Thanks!

EDIT

Lets say I want to fill out a dropdown box, that currently has 10 dynamic values. I would get these from the database using a simple select statement:

SELECT pet, value FROM pets

It would return a table like the following:

dog  1
cat  2
fish 3

I would enter this inside a dropdown box. However, if I could like have preferences added to that table, like user_id 100 would only see mammals (dog, cat) and user_id 200 would see only sea creatures (fish). Now imagine that the table has all the creatures of the world and i have a lot of tables that would require such preferences.

Since I can have unlimited users, I would have to apply some form of meta-data. Solutions to do this, is what I am looking for.

Shyam
  • 2,357
  • 8
  • 32
  • 44
  • Your preference table should also have some sort of "preference type" column. Some preferences are simple booleans, others might be dates, or integers, or strings. You may also want to include other indicators so that the preference UI can be somewhat automated - it would be a maintenance problem for each and every new preference to require its own UI coding. – Pointy Jan 01 '11 at 16:52
  • Oh, also, it's not at all clear what you're asking for here. Is there something wrong with your current solution? – Pointy Jan 01 '11 at 16:52
  • I know that preferences shouldn't be taken lightly. But I rather have a start on a model that could at least have some "preferences"; like initial values or visible items. The latter ones could be just using boolean types. – Shyam Jan 01 '11 at 16:54
  • There is nothing wrong, I want to add a feature to use the same solution for different kind of users (interaction tweaking). – Shyam Jan 01 '11 at 16:56

2 Answers2

2

This sounds like it has nothing to do with Server-Side JavaScript (which I don't think is a crazy choice) or your lack of a framework (which I do think is a little crazy). This is database and table design at its heart.

How you categorize a list of values from a table is up to you depending upon circumstances. For example, you may have a PETS table which has the data as you describe. Then, you may have a PET_ATTRIBUTE_LIST table, which would have data which PETS may possess. Finally, you could have a PET_ATTRIBUTE table which links these two. That way the attributes (fish, mammal, vertebrate, etc) are in one table, the pets (dog, cat, beta, etc) in another, and then an arbitrary set of attributes can be linked to a pet.

For the matter of users only seeing options which are important to them, you would have a USER_PET_ATTRIBUTE table linking records between your table holding users and your PET_ATTRIBUTE_LIST table.

There are a lot of the many-to-many relationships using this method, but it is probably the most flexible.

Adam Hawkes
  • 7,218
  • 30
  • 57
  • Sure, I agree. However the data from the database gets loaded inside JavaScript variables. I could generate a view to get a result specifically for that user. Got any reference material for such attribute lists (examples, best practices) ? – Shyam Jan 02 '11 at 13:27
  • Right, you want to do the heavy-lifting data-wise at the database/back-end side. You could do views or stored procedures which perform the filtering before the data gets sent to the front end. Whichever you prefer, really, but I like keeping things in packages/procedures/functions with ref cursors. – Adam Hawkes Jan 03 '11 at 17:00
0

I think you should reconsider your point of "not using a framework". Helma/Ringo is a mature and production-ready server-side javascript framework based on Rhino. An abstraction layer maps javascript objects to a relational database (jdbc connected), as well as already provides easy methods for user objects and preferences.

kstrieder
  • 26
  • 5
  • I consider to understand some concepts first prior adding a framework. I love abstraction; but I love the ugly parts too. I learn by practice, I discover when failing. So, using a framework just for ease would solve my problem technically. It wouldn't satisfy my hunger though. – Shyam Jan 01 '11 at 18:59