Building an App with the frostillic.us Framework, Part 2
Jul 11, 2014, 6:01 PM
- Building an App with the frostillic.us Framework, Part 1
- Building an App with the frostillic.us Framework, Part 2
- Building an App with the frostillic.us Framework, Part 3
- Building an App with the frostillic.us Framework, Part 4
- Building an App with the frostillic.us Framework, Part 5
- Building an App with the frostillic.us Framework, Part 6
- Building an App with the frostillic.us Framework, Part 7
- Define the data model
- Create the view and add it to an XPage
- Create the editing page
- Add validation and translation to the model
- Add notification to the model
- Add sorting to the view
- Basic servlet
- REST with Angular.js
The first stage of building a frostillic.us-Framework-based app was a bit unusual - focusing on creating a model object in Java - but the next phase is about as bog-standard as it gets:
Create the view and add it to an XPage
The view we'll need is a basic one showing all Notes. We'll name it "Notes\All" to match the expected prefix in the model and add our two expected columns: Title and Body. The model classes work with sortable columns, so we'll make Title sortable:
Once we have the view, we can refer to it in EL in an XPage as #{Notes.all}
. For demo purposes, we'll drop it on the page using a standard xp:viewPanel
- not the fanciest presentation, but it'll get the job done:
<xp:viewPanel value="#{Notes.all}" pageName="/note.xsp"> <xp:this.facets> <xp:pager xp:key="headerPager" id="pager1" partialRefresh="true" layout="Previous Group Next" /> </xp:this.facets> <xp:viewColumn columnName="Title" displayAs="link"> <xp:viewColumnHeader value="Title" sortable="true"/> </xp:viewColumn> <xp:viewColumn columnName="Body"> <xp:viewColumnHeader value="Body"/> </xp:viewColumn> </xp:viewPanel>
Here, I'm using value="..."
to specify the data source. There is also a normal data source for model collections, but it's rarely needed - the EL syntax is much more concise and clear, and it works well with relations (e.g. #{note.responses}
). I also specify a pageName="..."
for the generated links, since $$OpenDominoDocument URLs won't help here. I may add something to assist with that down the line, but for now specifying the page will do.
Other than those, though: pretty standard stuff. That's one of the goals of the framework: when it makes sense to do things the standard way, I want to do that - no need to reinvent every wheel. So the lists extend TabularDataModel
in addition to implementing List
and the model objects themselves implement ViewRowData
in addition to DataObject
.
The next topic - creating an editing page - continues this trend of working with the standard components while cutting out as much hassle as possible.