I'm using OpenRasta to create a Survey application.
I have a SurveyResource that is accessible at /surveys/{id} and editable at /surveys/{id}/edit
I'd now like to add questions to the survey, as that is the point of a survey, but I'm not sure what the most restful way of doing this is and how to set it up in OR.
I'm thinking I should have a QuestionResource (that has details of the question type, question text, etc) and it should be posted to /surveys/{id}/questions and handled by a question handler, but I can't work out how to configure OR.
I've pushed my project onto github at https://github.com/oharab/OpenSurvey/tree/add_question_to_survey
Can anyone help me?
Ben
it depends on the way you want to model your resources. It's perfectly possible that you'd never explicitly provide access to a single question, and would modify the entire survey document, like so:
PUT /surveys/123
<survey>
<link rel="update" href="/surveys/123" method="PUT"
type="application/vnd.mycorp.survey+xml" />
<question id="age">
<label>How old are you?</label>
<select>
<option>0 - 5</option>
<option>6 - 10</option>
<option>10 - 13</option>
</select>
</question>
</survey>
If you go this route, you could even use HTML, or HTML 5 for your content so it's easy to consume by clients. Now you're just modifying the entire survey document at once.
Alternatively, you might want to separately address each question, giving them an individual URI, which I think is what you're talking about, like so:
GET /survey/123
<survey>
<link rel="add-question" href="/survey/123/questions"
type="application/vnd.mycorp.surveyquestion+xml" method="POST" />
<question>
<link rel="delete" href="/questions/123-age" method="DELETE" />
<link rel="update" href="/questions/123-age" type="application/vnd.mycorp.surveyquestion+xml" method="PUT" />
<label>How old are you?</label>
<select>
<option>0 - 5</option>
<option>6 - 10</option>
<option>10 - 13</option>
</select>
</question>
</survey>
Neither of these is more RESTful than the other, the difference is only in granularity of call. If you need the granularity of the latter, then configure yourself a separate handler per resource as in
using(OpenRastaConfiguration.Manual)
{
ResourceSpace.Has.ResourcesOfType<Survey>().AtUri("/survey/{id}").HandledBy<SurveyHandler>();
ResourceSpace.Has.ResourcesOfType<Question>().AtUri("/questions/{id}").HandleBy<QuestionHandler>();
}
Related
I know that in my /page.html I can do:
...
<body class="lift:content_id=main">
<div id="main" class="lift:surround?with=default;at=content">
<title class="lift:head">TITLE_GOES_HERE</title>
...
... but it would be much more transparent for designers to be able to just put <title/> in the <head/> of a /page.html.
Would it be possible for a <title/> snippet used in /templates-hidden/default.html to somehow read the regular head <title/> in currently used /page.html?
Thanks!
I think the answer is rather "no", because Lift reads only the data inside id="???" in page.html. This is an architecture choice AFAIK.
You should ask on the mailing list, I think, if you propose any changes to the Lift architecture.
BTW, do you know that the title is overridden (inserted) if you use the SiteMap?: https://www.assembla.com/wiki/show/liftweb/SiteMap
Umbraco newbie here. I've researched a tonne but can't seem to find what I' looking for.
I have a site with a slider on the homepage, the slider is sitting in a macro which is using a for-each (of a nodes children) with a final goal to display the 'heroImage' image from that doctype. I cant post images as a newbie to this site, but heres my content structure:
HOME
PORTFOLIO
- First Item
- Another Item
ABOUT
CONTACT US
Home, Portfolio, ABOUT and CONTACT US are "Landing Pages" document types, and the children under Portfolio (First Item and Another Item) are "Portfolio Entries" document types. Below is the code on "Landing Page" calling the Slideshow macro.
Portfolio Entry has fields:
heroImage
images
body
Slideshow macro obviously being the highlight there. Easy enough. Heres my macro code where you'll see I'm trying to display the heroImage of the node in question for each 'for-each'.
<xsl:template match="/">
<!-- slider -->
<div id="slideshow">
<div id="slider" class="nivoSlider">
<xsl:for-each select="umbraco.library:GetXmlNodeById(1081)/*[#isDoc and position() < 4]">
<xsl:variable name="mediaId" select="umbraco.library:GetMedia(#id, 'false')/data [#alias = 'umbracoFile']" />
<xsl:if test="$mediaId > 0">
<xsl:variable name="mediaNode" select="umbraco.library:GetMedia($mediaId, 0)" />
<xsl:if test="count($mediaNode/data) > 0 and string($mediaNode/data[#alias='umbracoFile']) != ''">
<img src="{$mediaNode/data[#alias='umbracoFile']}" alt="[image]" />
</xsl:if>
</xsl:if>
</xsl:for-each>
</div>
</div>
<!-- data-transition="slideInLeft" -->
<script type="text/javascript">
$(window).load(function() {
$('#slider').nivoSlider();
});
</script>
</xsl:template>
I feel like im so close, and ran out of search queries as most of the solutions I found were dependant on the imageId being passed onto the macro from the other side of the macro which wouldn't work.
Hope Ive explained this enough and thanks in advance for your help!
First of all, it looks like you're hardcoding the parent node id. In the code you just provided, it seems to only be getting the children of the node with id 1081. From reading what you just posted, it would seem that on all landing pages, you want to display their individual portfolio entries.
Either way, I would stay away from hardcoding IDs. If the node id changes in any way(user deletes the node, it gets exported as a package to the live environment, etc), your code will stop working. I'd just use $currentPage instead.
Judging by your filter, I imagine you only want the first 3 items to show in the slider. The code seems correct, but you seem to be using the old schema and its associated xpath. If you're using a newer version of Umbraco, the way you reference node data in xslt would have changed. I would guess that you've found many code examples and tried merging them together, without realising they wouldn't call the same schema.
This wiki link will provide more information, and hopefully fix your problem if you're using the wrong xpath.
I'm having trouble about what to use from schema.org. I'm making a web site kinda similar to urbandictionary.com. Users are the contributors of the dictionary. Also the dictionary may include phrases like "2012 London Olympics", "MIT Dorms" etc. Whatever. So I want to add schema to the website. What should be schema-named the words/phrases and the users' descriptions?
http://schema.org/docs/full.html
Edit: layout of a sample page:
Gmail
Google's email service -user63
best email service in terms of spam prevention -user21
Gmail has a support of IMAP, POP3, SMTPi OAUTH, FRD, two-way secure login -userMew
Edit2: loyout of another sample page:
Batman 5
Upcoming movie of Batman, where Justien Bieber is going to play Joker -user43, May 2015
The opening was a disaster; Bieber slipped to the stairs and then was carried to a hospital -user22, December 2015
This movie was a disaster, a very poor quality movie -userKitten, March 2016
General
There is a getting started page in the documentation on schema.org. As you are building a dictionary, you might have an entry about a movie there (the example they are using). The markup could look like this:
<div itemscope itemtype ="http://schema.org/Movie">
<h1 itemprop="name">Avatar</h1>
<span>Director: <span itemprop="director">James Cameron</span></span>
<span itemprop="genre">Science fiction</span>
Trailer
</div>
This requires that you know that your data entry is a movie of course. If you do not know that, you could use the itemtype Article (or even Thing) and the global properties name and description.
There is also additional information about the format of e.g. dates and how to integrate invisible data using the meta tag and setting a content attribute: <meta itemprop="bestRating" content="5" />.
You can always give multiple types to an item by specifying the property additionalType. You can even extend the schema. But you should use them carefully as they are not recognized by search engines, but might get used in the future:
If the schema gains adoption and proves useful to search applications, search engines may start using this data.
In general, all this markup is optional, so feel free to mark up as much as possible, but only those parts that make sense. From the schema.org FAQ:
It is fine to mark up only some properties of an item - markup is not an all-or-nothing choice.
Markup validation
To test your markup, Google provides a Rich Snippets Testing Tool. You can paste your HTML there and see what Google extracts from it. For the above example, this is the result:
Item
Type: http://schema.org/movie
name = Avatar
director = James Cameron
genre = Science fiction
trailer
text = Trailer
href = http://www.example.com/movies/avatar-theatrical-trailer.html
On your page
As the information on your page is user-generated, you could let the users choose from the higher level schema.org types (Movie, Place (MIT Dorms), SportsEvent (2012 London Olympics) etc.) and fallback to Thing. Then get the data in form elements matching the properties of those types. Save the data and evaluate it when you build your dictionary pages. It is then crawled by Google (and others) and used for indexing.
For the Gmail example you gave, the markup could simply look like this (copy and paste it into the testing tool to see that Google understands the nesting):
<div itemscope itemtype ="http://www.schema.org/SoftwareApplication">
<h1 itemprop="name">Gmail</h1>
<div itemprop="comment" itemscope itemtype="http://www.schema.org/Comment">
<span itemprop="comment">Google's email service</span>
<span itemprop="author">user63</span>
</div>
<div itemprop="comment" itemscope itemtype="http://www.schema.org/Comment">
<span itemprop="comment">best email service in terms of spam prevention</span>
<span itemprop="author">user21</span>
</div>
<div itemprop="comment" itemscope itemtype="http://www.schema.org/Comment">
<span itemprop="comment">Gmail has a support of IMAP, POP3, SMTPi OAUTH, FRD, two-way secure login</span>
<span itemprop="author">userMew</span>
</div>
</div>
Additional information
For more information see the Google schema.org FAQs. Also see the Dublin Core Metadata Initiatice (DCMI) (Wikipedia) as an alternative way to semantically markup your data. They also have a wiki page for mapping between schema.org and DC.
Dictionaries can now be represented in schema.org in several ways. At the moment the google search results are not based on structured data/schema.org but that may change in future.
Most of the suggestions below are more specific types of http://schema.org/CreativeWork - which is important because it contains properties like comment, contributor, and text which are useful for user-editable content and contributions. CreativeWork also contains learningResourceType which can be set to dictionary - but this isn't a suggested value by schema.org so search engines may not know where to look.
SEO and Semanic HTML for dictionaries
Using the tags with and is the standard way of doing dictionary terms/definitions and used by the top dictionary websites, you can these tags with the schema inside them,
<div itemscope itemtype="http://schema.org/Collection"><h1 itemprop="name">Dictionary</h1>
<dl id="gmail" itemscope itemtype="http://schema.org/CreativeWork">
<dt itemprop="name">Gmail</dt>
<meta itemprop="sameAs" content="http://gmail.com">
<meta itemprop="url" content="http://mydictionary.com/page1.html#gmail">
<dd itemprop="description"><span itemprop="comment">Google's email service</span> -<span itemprop="contributor">user63</span></dd>
</dl>
</div>
Having a separate page (or breadcrumb) for each terms seems key to ranking highly. The page name (including any bookmark) is used in the ranking, so if you search for 'ardvark' the URL http://mydictionary.com/A will rank below http://mydictionary.com/Aardvark even if both pages are otherwise identical.
Explanation of 3 Suitable schema types, including the 'official' dictionary
Method 1)
Use http://schema.org/Thing or http://schema.org/Intangible with only name (your term) and description (your definition) set. This will be hundreds (or more) of separate ones, so you could group them under a collection with http://schema.org/Collective (this how VideoGallery and ImageGallery structured data is done). The nice thing about this is it's simple and very each to show each on a separate page, which should increase hits.
Method 2)
The only way that the schema will recognize the value of Dictionary as a Dictionary is to use http://schema.org/publicationType - which can be any one of the values listed here - one of which is Dictionary. Another is Terminology.
The catch is that at the moment publicationType can only be used inside http://schema.org/MedicalScholarlyArticle - but raise a request and this may be expanded, for example to other ScholarlyArticles, or to CreativeWork (which is a parent of MedicalScholarlyArticle). MedicalScholarlyArticle is a type of CreativeWork - as explained above. If using MedicalScholarlyArticle you can nest items inside, one for each term, possibly using http://schema.org/Thing or http://schema.org/Intangible (set name and description, sameAs can be used to point to a wikipedia or urban dictionary entry that identifies the term, or to social media).
You can open an issue here to request that publicationType be added to all CreativeWork.
Method 3)
A dictionary is a book (whether offline or online), so use http://schema.org/Book and add each term within it by nesting inside. Book is a type of http://schema.org/CreativeWork and as in Method 1 you can set the terms with Thing, Intangible, or even make each term into it's own CreativeWork (just check because google may want an image for each as it does with each ScholarlyArticle).
I have a feature which is provisioning 1 document library and 2 custom lists. A folder is included for each list containing the schema.xml for that list. Each folder also contains the associated forms (AllItems, DispForm, EditForm, NewForm, etc.). Everything deploys/works correctly but it seems a little redundant having the same forms copied into each list's folder. There is nothing special about these lists - the are basically a default doc library/generic list with additional fields provided through new content types (derived from Item/Document).
As far as I can tell these forms are pretty generic. Are there pre-installed forms that I can reference from my list so I don't have to deploy all of these extra files? Is there any reason I would not want to do this?
Update - moving xml in comment to original question for readability:
<Forms>
<Form Type="DisplayForm" Url="Forms/DispForm.aspx" WebPartZoneID="Main"/>
<Form Type="EditForm" Url="Forms/EditForm.aspx" WebPartZoneID="Main"/>
<Form Type="NewForm" Url="Forms/Upload.aspx" WebPartZoneID="Main"/>
<Form Type="NewFormDialog" Path="EditDlg.htm">
....
There are virtual defaults that are used if you don't specify a concrete page.
All lists use these template defaults unless you use a tool like SharePoint designer to customize the page. Then the template is used to create the concrete page and you can customize the look for a particular list without affecting others.
For my custom definitions, I use
<List>
...
<MetaData>
...
<Forms>
<Form Type="DisplayForm" Url="DispForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" />
<Form Type="EditForm" Url="EditForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" />
<Form Type="NewForm" Url="NewForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" />
</Forms>
</MetaData>
</List>
If you have no reason to customize the out of the box version of these forms, you can use the virtual form and not deploy copies.
I have a large form that consists of all the input (text, checkbox, radio, etc...), I have them grouped together in a fieldset tag and a legend for each feildset. Each input has a label associated with it as well. My question is what is the best approach to display the information on one screen and take advantage of the horizontal real estate the user might or might not have?
I would love it to be all CSS with minimal (if any) table layout(s) as I think tables are for tablature data and not presentation. CSS3 and HTML5 are welcome as well.
Also I would like to have the ability to add branding as this might need to look like another site instead of the original site developed for.
What would be the best approach for this? I have the idea I would use li tags to do the horizontal look but I would like to break to the next line at the end of the screen (Think no scrolling horizontal but vertical is okay)
CSS Novice looking for design pattern advice
This is an example but I think I have around 50 fields
<!DOCTYPE HTML>
<html>
<head>
<title>Large Form</title>
</head>
<body>
<form action="">
<fieldset>
<legend>***</legend>
<label for="fname">First Name</label><br />
<input type="text" name="fname" id="fname" value="" /><br /><br />
<label for="lname">Last Name</label><br />
<input type="text" name="lname" id="lname" value="" /><br /><br />
<label for="gender">Gender</label><br />
<select name="gender" id="gender">
<option value="">-- select</option>
<option value="male">Male</option>
<option value="female">Female</option>
</select>
</fieldset>
<br />
<input type="submit" value="Submit" />
</form>
</body>
</html>
The first thing that comes to mind is that you want to remove the <br/> tags from the form. If you need vertical space, use CSS padding and margins since they're easier to change and make spacing consistent.
With that out of the way, other than branding (which will influence the look and feel of the form the most) the things you want to consider the most are accessibility and ease of use. Your use of labels and unwillingness to use tables for layout are a good start for accessibility so I'm not going to mention it further.
For ease of use, you'll need to make sure that each field can be tabbed to (in an order that makes sense), has a clear, meaningful label, has no unnecessary validation rules (such as forbidding whitespace in a phone number - don't force the user to clean data that can be cleaned automatically) and those validation rules that are necessary have clear, easy to understand messages that appear, ideally, as the user is entering the data rather than waiting for the user to submit the form.
Each of your field sets should be visually grouped either by colour, with a border or some other method. Individual field set should not be broken up, but different field sets can be separate from each other as long as they are contextually different (like address versus interests, for example).
Since you're already grouping field sets, you can use them as your basic unit of page layout. Each set could be floated, for example, in order to maximimize horizontal usage regardless of the user's browser width. As long as the sets are visually distinct enough and are clearly labelled there shouldn't really be any issues with that.
If consistency is more your thing, then each field set should be separated from each other vertically. That would make sure the form is ordered and laid out the same way for every user. Again, the important thing is visual consistency and ease of use. Users are used to forms being laid out vertically so the wasted horizontal space of doing it that way shouldn't be a very big concern.
Just remember: you're making something that should be easy to use and not frustrating. The position of fields should reflect that: they should be natural, grouping like fields together and separating groups of like fields from dissimilar fields. As long as you're keeping that in mind you're probably in good shape.
And don't forget to do some quick usability tests to make sure your validations make sense and are clear.
Have a look at CSS3 grid positioning. It has a clear but powerful syntax, e.g. from the link:
body {
grid-columns: * * (0.5in * *)[2];
grid-rows: 20% *;
columns: 3;
column-gap: 0.5in;
}
Elements use gr units to choose their grid cell:
img {
position: absolute;
left: 2gr;
width: 3gr;
}
You would only have to give an id to your fieldsets then set their position and extents in your style file.
One of my favorite ways to group large forms is with the jQuery style accordion. It allows you to abstract the form into key groupings, keep the form all on one page, and eliminate the need for page scrolling; all with an intuitive user interface.
A good example of this is the Barnes & Noble checkout form process.
Check out CSS Flexbox for some liquid flexibility withing you design sets. I would also recommend picking a "style" and sticking with it. Agree with Welbog.
I guess that if you have a form with 50 fields, you surely have to split it to themed tabs. Say 3 to 5 tabs. They can be implemented by Javascript.
You may want to save input data on-the-fly, because the user may need a long time to finish the form, so there is bigger possibility that he will catch a loss of internet connection or some other factor, that will erase his half-finished form, which would probably dissapoint him and leave your site.
Also consider that user has to have a place for his eye to rest, so be sure to make enough blank room between inputs.