Design pattern to keep UI text separate from UI widgets - user-interface

The R Shiny app I am building is going to require both (1) some large blocks of text in the UI, and (2) some complexity in the UI design. I am concerned that combining this all into the same file will create significant clutter. Hence, I am looking for a design pattern to help keep the UI-text separate from the UI-functionality.
For example, the following code includes alternating text and functionality.
Editing UI-text will require navigating around chunks of UI-functionality.
Editing UI-functionality will require navigating around chunks of UI-text.
# chunk of functionality
tabPanel(
title = title,
fluidRow(
column(width = 3,
wellPanel(
# chunk of text
h4("heading text"),
p("lots of text in this paragraph"),
p("lots of text in this paragraph"),
# chunk of functionality
),
div(style = "height:3px"),
hr(),
actionButton("button1"), "label1"),
wellPanel(
# chunk of text
h4("heading text"),
p("lots of text in this paragraph"),
p("lots of text in this paragraph")
)
)))
Approaches I have considered:
Every chunk of text could be pulled out into its own shiny module. However, this seems overkill when there is no server functionality for each piece of text.
Create the text chunks using the server and insert them into the UI. However, this will likely just move the complexity into the server and may impact performance as the server has to pass all the text to the UI.
Creating a list that stores all the text chunks and insert text from this list seems the best candidate approach, but it is not clear how/if this will handle text that needs to be updated while the app runs.
I accept that whatever design pattern I choose will also constrain the development approach. But I have struggled to find any discussion of the handling of UI text, and no discussion of how to approach this in Shiny.
What is an effective design/development pattern to keep UI-text and UI-functionality separate?

The design pattern I ended up using matches the suggestions of #Stephane and #Vida.
app file
# chunk of functionality
tabPanel(
title = title,
fluidRow(
column(width = 3,
wellPanel(
text_chunk_1()
# chunk of functionality
),
div(style = "height:3px"),
hr(),
actionButton("button1"), "label1"),
wellPanel(
text_chunk_2("heading goes here")
)
)))
supporting file
text_chunk_1 = function() {
tagList(
h4("heading text"),
p("lots of text in this paragraph"),
p("lots of text in this paragraph")
)
}
text_chunk_2 = function(heading_text) {
tagList(
h4(heading_text),
p("lots of text in this paragraph"),
p("lots of text in this paragraph")
)
}
Adding this abstraction also prompted me to abstract out other parts of the app. For example: where chunks of functionality are repetitive, the reused parts could also be moved out into a supporting file.
Note that once I moved more than just the text strings to the supporting file, the functions need to return a tagList. For example:
"paragraph text" can be returned without a tagList
it might work to return one p("paragraph text") by itself though I would prefer a tagList
but two or more items need a tagList:
p("paragraph1"), p("paragraph2") will fail
tagList( p("paragraph1"), p("paragraph2") ) will work

Related

Find the number of displayed lines, with folding in Ace

Within an Ace editor, it is easy to find the number of lines in the edited document with the following:
myEditor.session.getLength();
But languages like JSON or XML can be "folded." That is, children properties or elements can be collapsed so only one single line is displayed for the parent.
Is there a way to get the number of lines actually displayed? Something like the following:
myEditor.session.getVisibleLength();
Note: the ultimate goal is to have an editor that adapts its height on the page to the content it displays (if lines are collapsed, then it should shrink, and if collapsed lines are expanded again, it should increase its height.)
UPDATE: After a user's response, I use the following. This is not the answer to the specific question I asked above, but rather the perfect answer to what I was trying to achieve overall:
const myEditor = ace.edit(elem, {minLines: 5, maxLines: 50});
To automatically change the height of the editor use maxLines option, but don't set it to a very large value as performance depends on the number of displayed lines.

iText7 MoveText vs SetFixedPosition different results

Why do I get different results when I use MoveText vs SetFixedPosition? I use the same x and y value but they print on the page in different location. If I use canvasPage.BeginText can it be formatted to use a width and word wrap
canvasPage.BeginText()
.SetFontAndSize(PdfFontFactory.CreateFont(StandardFonts.HELVETICA_BOLD), 21)
.MoveText(X,Y)
Paragraph p = new Paragraph()
.Add(_disclaimer)
.SetFixedPosition(X,Y, canvasPage.W)
.SetFont(PdfFontFactory.CreateFont(StandardFonts.HELVETICA))
.SetFontColor(ColorConstants.BLACK)
.SetFontSize(12)
.SetTextAlignment(TextAlignment.LEFT);
The locations between the cases when you add text onto the canvas manually with low-level operations versus the case when you use high-level layout Paragraph objects will be different because Paragraph is responsible for multi-line layout and adds necessary margins / spacings for the text to look nice and not overlap with other content. The locations are still different only by a minor offset.
You cannot combine low-level beginText operation with high-level layout requirements (wrapping text across lines etc) - this is the responsibility of layout's Paragraph.

Converting bold text within a .doc to marked-up text programmatically

I am currently dealing with a large .docx file (roughly 400 pages). It is divided up into sections that are very easily digestable by humans and look like this :
Bold text
Written paragraph
This is perfectly humanly readable and great. Unfortunately we have an in-house program in our University that uses the mark-up of .docx files to sort them out/do some processing on them. By this I mean that sectioning a .doc/.docx using only bold markup is not enough, you must use the in-built tools within MS Office to do this (as below) :
So what I need to write is a simple script that will find the text that is bold within a .docx document and convert this text to properly marked up "Heading 1"s, or similar. It doesn't concern me whether or not the .docx file format is maintained or anything like this.
is it possible to do this? What APIs/languages/tools should I start looking into to accomplish this relatively simple task?
Using a short VBA macro you can iterate over all paragraphs and change the style for all paragraphs containing only bold text into a heading style:
Sub FormatBoldAsHeading()
Dim p As Paragraph
For Each p In ActiveDocument.Paragraphs
If p.Range.Font.Bold <> wdUndefined And p.Range.Font.Bold Then
p.Style = WdBuiltinStyle.wdStyleHeading1
End If
Next
End Sub

Implementing Emoticon in windows store chat

I am developing a Windows Store chat app.
In this apps, I am using a TextBox to receive message content from the user. I want to implement Emoticons (Smileys) such that typing a code gives a respective image inline with the text.
For example, for :), I want to have a 'smile' image.
What you'll need to do is use a RichTextBlock to display your text. This will give you access to a adding in an InlineUIContainer block where necessary.
So, your process will be:
Accept text in a regular text box
Parse the text into a series of Inlines (Run, InlineUIContainer, etc)
Create a new Paragraph for the message
Add the Inliness to the Paragraph.
Add the Paragraph to your RichTextBlock's Blocks property (a BlockCollection).
For each piece of text:
Split the text, likely using Regex, searching for the keys which trigger an Image (':)', '(heart)', etc).
For each non-image text, create a Run with the Text set to the text of the split
For each Image, create an InlineUIContainer and an Image. Set the Image source to the proper Image path, then set the Child of the InlineUIContainer to the Image.
Add the Run or InlineUIContainer the Paragraph via Paragraph.Blocks.Add(Inline).
Certain icons may be included in the Segoe UI Symbol Font Family. If this is the case, you may choose to not use an Image for that symbol, and instead use a Run with the FontFamily set to Segoe UI Symbol. You can play around with the FontSize if you want them to be more prominent.
Hope this helps and happy coding!

Splitting Ruby strings into pages

I've been thinking about this problem for a while, and not quite sure the best way to go about it.
In a rails app I have books, which have many chapters, which have many sections. Chapters are basically just containers for sections, though may contain strings of text themselves. The sections hold most of the book text.
I'm planning to build an HTML 5 ebook reader that works in a mobile browser, and I don't want the user to have to scroll down -- I want the text to break at the end of the page.
I'd assumed using split might be the way to go, but I'm not sure there's a way to break at regular intervals? Would a javascript option work better here?
I'd looked at this: Dividing text article to smaller parts with paging in Ruby on Rails but can't feasibly insert manual break marks in the text, some of which are 90,000+ words.
Any ideas would be appreciated.
I think the main problem here is that the page length will depend on the device (and possibly the text size, if that is feature of your app). You should probably send large chunks that are sure to be at least say 5 pages long, at a time and then let the javascript do the paging. Rails has no access, nor should it, to the size of the display.
Text requires very little data, you shouldn't worry about transmitting more than you need or keeping too much in memory.
You may use blank line("\n" or "") as the separator.
I'd send enough of the page content down to easily fill a page and more, then use javascript on the client slide to remove sentences from the page until the scroll-bar disappears.
Resize.js is something similar I wrote a while ago. I wanted to enlarge/reduce the font size used on a screen until the screen was just full (for a dashboard monitor).. Yours would be similar, but instead of changing the font size, you are trimming off sentences.
Let me know if you can't see how to adapt this code.
Note: I would also make the javascript note the amount of text it ends up displaying, and pass that to the server in the 'next page' request, so the server knows where to start the next page from.

Resources