Tabular data? Can I do this in UR?

[luke]

Hello,

I'm writing some articles and need to store them along with different bits of data about them:
- the different places online where I've published them
- the sites I'm promoting for the article
- when I did submitted

And I need to be able to filter articles that have already been published to particular place.

So I'm looking to be able to see stuff in some kind of tabular form...

Finding an application to do all this is kind of doing my nut. 500 word articles don't fit conveniently in Excel. I've thought about using Access but don't really fancy the learning curve.

Is there any way this could be done with UR?

thanks,

Luke

[quant]

this can be done in UR very nicely.

Make folders "Articles" and "Websites", where you store your articles and links to websites.

Create attributes "article" and "website" that will be of type "info item" (new in UR 3.5). Create another attribute "date submitted" of type Date.

Now create template "publication" with those attributes assigned.

Create folder "Publications". When you make a new submission, you create "publication" item (could be made as default for that folder). As attributes, you link website from Website folder and an article from Article folder, + submitted date (this can be defaulted to Today for you for example).

UR powerful search will allow you to do easily all the searches you mention ...

[ashwken]

quant,

This is very insightful, the "Publication" folder acts as an intermediate table between "Articles" and "Websites".

Playing around with your suggestion, I tried writing a Title Expression for the "Publication" Submission Event Item:

[Submit_Date] || " - " || [Submit_Article]

and discovered that the expression returns the following:

2008-06-27 - 1029,1026,1000

which appears to be the node path back to the Root for the linked Article (Info Item).

[quant]

Originally posted by ashwken
[Submit_Date] || " - " || [Submit_Article]

and discovered that the expression returns the following:

2008-06-27 - 1029,1026,1000

which appears to be the node path back to the Root for the linked Article (Info Item).

yeah, I'm aware of that, one of the first questions I asked Kinook after they introduced info item attributes in UR ...

"The way it's implemented (item titles), they're only dynamic in the sense that if the user changes an attribute (in the same item) that is used in the title, the title will update to reflect that change. Values from other items (i.e., parent title) aren't supported."

[ashwken]

Originally posted by quant
yeah, I'm aware of that, one of the first questions I asked Kinook after they introduced info item attributes in UR ...

"The way it's implemented (item titles), they're only dynamic in the sense that if the user changes an attribute (in the same item) that is used in the title, the title will update to reflect that change. Values from other items (i.e., parent title) aren't supported."

Uhmmm, trying to understand Kinook's statement...

This screen shot shows that [Submit_Article] has a value which is the Item Title from the Lookup (Info Item), but the expression is returning the node path.

In this particular example I would think that you would want a meaningful title for the Submission Event, granted the Publication folder is going to be used primarly for Searches, but still a more descriptive title in the Search Results would be helpful.

Don't get me wrong, I'm not down-playing your suggestion but trying to work it thru because it has application to many different situations.

EDIT: Oh OK, the value for [Submit_Article] is actually the node path for the Item returned from the Lookup, even though it is showing an Icon and the actual Item Title.

Edit-II: Modified the Title Expression to the following:

[Submit_Date] || " - " || [Submit_Website] || trim(coalesce ([Update_Title],''))

this removes the [Update_Title] Attribute from being required as part of the Title Expression, previously (as shown in screen shot) it required a value for the expression to evaluate.

[quant]

Originally posted by ashwken
In this particular example I would think that you would want a meaningful title for the Submission Event, granted the Publication folder is going to be used primarly for Searches, but still a more descriptive title in the Search Results would be helpful.

Don't get me wrong, I'm not down-playing your suggestion but trying to work it thru because it has application to many different situations.

I completely understand. I expected the same thing as you do, this is what I was asking in email:

"when I try to use for the title attribute based on info item, it displays list of items' ids ...
that was unexpected, I thought it would display that item's title, not it's id. I was kinda hoping that one could have items that would update its name according to attributes of another item, that would be cool "

Info item attributes are really powerful. In fact I was expecting "info items" when I joined UR community, cause UR is based on sql database, and these things are just basic building blocks in relational databases.

It would be nice if item title could consists of item titles from another items, I think it's a natural next step in the "item title customization" feature set. But on the other hand, all the info is readily available in the child pane if one wishes, so I personally don't see it as a big drawback not having that feature at the moment ...


Kinook is slowly releasing more and more database power, I hope we will be able to run sql queries in UR some time down the line as well ;-)

[ashwken]

Originally posted by quant
It would be nice if item title could consists of item titles from another items, I think it's a natural next step in the "item title customization" feature set. But on the other hand, all the info is readily available in the child pane if one wishes, so I personally don't see it as a big drawback not having that feature at the moment ...

Yes, it does seem like a natural expectation, especially since the Lookup Item Title value is being returned to some part of the program - just needs to be parsed.

Yes, the created Attributes can be added to the Child and/or Search Results panes.

I wonder if any of this is going to help Luke?

[kinook]

It was an oversight that custom titles don't display the title properly for an info item type attribute (instead, it displays the path of item IDs for the item). We do intend to rectify that.

[luke]

A very interesting solution... Thanks for explaining this. That screen shot helps a lot.

Being honest, looking at it, I don't think I'd want to use it in that particular way. Because of the way the data is structured.

I'll be submitted each article to 10 sites let say. The same 10 sites for each article. So here, for submitting 10 articles that'd be 100 seperate operations.

Tabular structure, with the ability to update the 10 article fields at once would still probably be best for me...

It's intriguing to see this relational database structure in UR though.

A more basic idea that you've given me is to simply use custom attributes on the article nodes: website1, website2, website3, and tick them off when submitted.

But that's just 2 dimensional though, hmmm...

So actually your solution is pretty brilliant, I see that its tricky to hold article, submission-website and date of submission (per submission website) in any application because you *have* to get into the intersection table: Article_Website_Datesubmitted - with one record per submission. Which you've amply provided.

I think I'm gonna have a to drop the date attribute (from database format). In fact if I have one date for a bunch of submissions then I can get by with custom attributes on Article items: 1 per submission website and a 1 for submission date.

That should work... Thanks again for explaining.

Luke

[quant]

Originally posted by luke
Being honest, looking at it, I don't think I'd want to use it in that particular way. Because of the way the data is structured.

I'll be submitted each article to 10 sites let say. The same 10 sites for each article. So here, for submitting 10 articles that'd be 100 seperate operations.

Tabular structure, with the ability to update the 10 article fields at once would still probably be best for me...

You have the same ability in UR! Just select the items you want to update, go to attributes pane, and change the given attribute ...

[luke]

It's the other way round I want. I'd want to update multiple attributes

In other words I'd want to go across the 10 different submitted-website columns in the same row, in one go.

You've showed some really neat stuff I have to say. I never knew you could update an attribute in multiple items.

[ashwken]

Uhmmm, this is interesting...

EDIT: This is working now, sorry.

The Chose List for an Info Item is only available thru the IA Pane (Ctrl-4), it is not available from a Form.

Also, when originally create/assign an Attribute that is an Info Item to a Template, you are returned to the IA Pane and the Chose List pops-up.

Generally you would not want to assign a default value at the Tempalte level so you chose Cancel on the Chose Item Dialog giving you a blank value (a value is chosen when the new Item created).

But let's say that you want to come back (to the Template) at a later date and set a temporary default value for a Info Item, once you are thru with this temporary useage you can NOT re-blank the value at the Template level - something must be selected.

This is what I'm seeing.

[ashwken]

Originally posted by luke
It's the other way round I want. I'd want to update multiple attribute,

In other words I'd want to go across the 10 different submitted-website columns in the same row, in one go.

You've showed some really neat stuff I have to say. I never knew you could update an attribute in multiple items.

Because the Submissions folder is an Intersection table it's going to have a load of records, one for each Submission Event. Eventually you may want to move these into a date-grouped (sub-)folder structure. The Searches that you build against the Submission Event Item will be based on:

Item is Submission (template)

if you do not restrict the Search to a particular location, Submission Items will be returned regardless of their location within UR (as long as they meet any additional Search parameters).

As you have pointed out you will need to "touch" each record (Submission Event).

For example: submit on the same day, the same Article, to (10) different Websites (Publishers).

Create a new Submission Item, do not set any default values, copy/paste the Item to the Submissions Folder, this will create a series of "Untitled (x)" Items. Select the series of Items and from the IA Pane (Ctrl-4) set the values for [Submit_Date] and [Submit_Article]. You will still need to "touch" each Item to set it's other required value [Submit_Website].

To streamline this you could have groups of Submission Items pre-built (blank, by Publisher), then copy/paste as needed.

[ashwken]

Originally posted by ashwken
Also, when originally create/assign an Attribute that is an Info Item to a Template, you are returned to the IA Pane and the Chose List pops-up.

Generally you would not want to assign a default value at the Tempalte level so you chose Cancel on the Chose Item Dialog giving you a blank value (a value is chosen when the new Item created).

But let's say that you want to come back (to the Template) at a later date and set a temporary default value for a Info Item, once you are thru with this temporary useage you can NOT re-blank the value at the Template level - something must be selected.

OK, I've been working thru this and it would seem that you do want to give the Info Items a default value in the Submission Template, the default value would be the Folder that contains the respective Child Items:

Submit_Article = Articles Folder

Submit_Website = Websites Folder

Then for a new Submission Item these values can be re-set to an actual Item - the Choose pop-up will be focused at the current value (Articles or Websites Folder), might save some time navigating the Choose pop-up (shows the current state, collasped or expanded, of the Data Explorer tree).

It still appears that once a value is given for an Info Item at the Template level, that value can be changed, but you can not revert to a blank value. 'Course, in light of the above, is there a valid reason for wanting a blank value?

[kinook]

Originally posted by ashwken
It still appears that once a value is given for an Info Item at the Template level, that value can be changed, but you can not revert to a blank value. 'Course, in light of the above, is there a valid reason for wanting a blank value?

To revert an info item attribute to a blank/null value, delete the attribute from the item and insert it again.