Thursday, August 14, 2014

Link Data 3

Unfortunately, I'm back to wondering again.  I thought of something last night that might throw a wrench in things.  Then again, it might make things really cool as well.

I realized that a user might want to create lists where each item contains more than one field.  For example, say you were creating a restaurant menu.  There is a list of items in the menu, each with a name and price (we'll pass on the description).  You could possibly create a separate idea for each item and just link them to the menu.  That was what I initially figured people would do.  However, what if the user wanted those items to be specific to that menu?  In other words, if the menu is deleted, they want the menu items deleted as well.  The items are literally a part of the menu.  My current method wouldn't allow that.

Then I realized that I could change my implementation of lists entirely.  Rather than a list having a specific data type, they will each have a link type I mentioned in previous posts, except that it will no longer be called a "link" type in this context.  Basically, lists will be lists of mini-ideas.

The average list will probably have only one field inside it's mini-idea type, in which case it will behave as it would if the list had a specific data type.  This way, if someone wanted to link to another idea, they could put an link field in the mini-idea type.  The confusing part about this is that they can add multiple link fields.  It wouldn't be too bad coding it under the hood, but creating an interface for that is beyond me at the moment.  I have to do alot of thinking.

That's where I'm at right now.  Thanks for reading!

clevceo

No comments: