Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The current code is a good start and can be made to "scale" into large apps that avoid hard-coding and have clear MVC separation with just a few changes. </p> <blockquote> <ul> <li>This should ideally be a widget or some sort of packaged functionality</li> </ul> </blockquote> <p>A widget will make reusing comment functionality easier and provide for reuse in different pages/apps. Extend the encapsulation and separation of concerns not only to the presentation, but also to the widget model. When you think of a comment field, it's intuitive to think of the state of the component as the comment text, yet all the parameters affecting it's behaviour can be part of it's model, including validation parameters. So, in addition to the comment text, I would have the model include:</p> <ul> <li>a mapping of character count to a size-category (too-small, small, medium, large, overflow).</li> <li>the max comment submit frequency (15 seconds)</li> </ul> <p>The widget model updates the size-category as the text is changed. The view listens to changes to the size-category, and the size-category value used to update the text class to produce CSS-styling for different comment lengths. The size-category is also checked when "Add Comment" is clicked. If it is "too-small" or "overflow" then a popup can be shown. Note that the Add Comment handler does not checking character count - that is isolated in the model - it checks the size-category. If necessary, the "Add Comment" controller could use the same mapping of character count to size-category that the model uses to produce helpful messages for the user. E.g. "Comments must be at least 15 characters" where 15 is fetched from the size-category map. </p> <p>The model also provides a "number of characters left" property whose change events are used to update the widget's UI. The maximum character count is fetched from the character to size-category map.</p> <blockquote> <ul> <li>Things like a comment per 15 seconds, and minimum 15 character comment belong to some application wide policies rather than being embedded inside each widget.</li> <li>Too many hard-coded values.</li> <li>No code organization. Model, Views, Controllers are all bundled together. Not that MVC is the only approach for organizing rich client side web applications, but there is none in this example.</li> </ul> </blockquote> <p>There may be many types of comments (e.g. different items being commented on) and different types of comment-widget. If they should all have the same minimum/maximum range then they should all be parameterized with the same model values controlling the comment validation. This is best done server-side when building the data for the comment model. The comment text is fetched for that specific comment, and the comment validation values, such as size-category mapping are fetched from page or application configuration defaults. By having central logic for producing the component validation model, adding new rules becomes much simpler - e.g. such as "moderators can post comments upto 1K", becomes a change in one piece of code. Another point to having the component model computed server side is that the model should also be validated server-side - client validation is more a user-convenience (inconvenience some might think!) - and not a hard enforcement. JavaScript can be disabled and HTTP requests constructed independently from the validating client.</p> <p>To sum up, much of this can be seen as organizing production of the widget model server side. By doing this server side, the server can enforce validation rules and shield the widget from the complexity of the rules and application-wide configuration.</p> <p>I've not mentioned jQuery or any UI technogy since this pattern is valid for applications irrespective of UI technology. How you apply the pattern will be UI-specific to some extent such as how the validation model is provided to the widget, or how to hook up listeners to the model, but the organizational level of the pattern is orthogonal to the UI. The primary focus is on the model - extending it to include validation aspects and computing it server side. Once that is in place, the organization problem is pretty much solved.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow would you organize a large complex web application (see basic example)?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USmdma
    1. USmdma
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for this nice answer. It's going to be a tough choice :)
      singulars
      1. PO
      1. USAnurag
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload