Changes for page Creating A Person Manager Application

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -304,9 +304,7 @@
304	304
305	305	This line...
306	306
307		-{{code}}
308		-= People=
309		-{{/code}}
	307	+{{code}}= People={{/code}}
310	310	...is just XWiki syntax saying "Give show me some "header" text with a big, bold font, that says "People".
311	311
312	312	These lines...
...	...	@@ -461,6 +461,7 @@
461	461	Press "Save & View", go to the "Joe Smith" page, and it should now look the way we want.
462	462
463	463	Some things to note about this code:
	462	+
464	464	* We called the "getObject()" method on the "special XWiki variable" $doc to get the Person instance on this page.
465	465	* We used the [[XWiki Box>>https://extensions.xwiki.org/xwiki/bin/view/Extension/Box%20Macro]] to put everything in a box.
466	466	* We included some CSS here that didn't do much, but could have been any arbitrary CSS:
...	...	@@ -468,16 +468,17 @@
468	468	* We wanted the CSS line to apply to what could potentially be many lines of following code. We used the [[XWiki Groups syntax>>https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/?syntax=2.1&section=Groups]] of ~(~(~( ... ~)~)~) for that.
469	469	* To make the image span two columns of our table, we used an XWiki [[Parameterized Table>>https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/?syntax=2.1&section=Tables]]
470	470	* For the "relatedPeople" property, we didn't want to just display the (multiple) Person names, we want them to be links. So we loop through them, creating a link for each.
471		-* We are careful to put "~#~#" at the end of each line when we want to put multiple things in a table column, so as not to confused XWiki.##
472		-* By using this code rather than blindly looping through every property, we're able to:
473		-** leave out the "age" property
	470	+* We are careful to put "~#~#" at the end of each line when we want to put multiple things in a table column, so as not to confused XWiki.
	471	+* By using this code rather than blindly looping through every property, we're able to easily:
	472	+** Not display the "age" property at all
474	474	** reorder the properties in any way we like
475	475	** use any labels we want, not be stuck with the "Pretty name" for each property (though this is more of a drawback than an advantage)
476	476
477	477	As you can see, this code to customize how we display a Person is extremely straightforward:
	477	+
478	478	* We easily got the value for the Person instance on the page.
479	479	* The Velocity syntax is simple and doesn't get in our way. We could someday choose Groovy if Velocity is not enough.
480		-* We're able to inject CSS if needed. We could also have done HTML.
	480	+* We're able to inject CSS as needed. We could also have injected raw HTML.
481	481	* We chose to use XWiki syntax, which is even simpler than HTML.
482	482
483	483	= Conclusion =
...	...	@@ -484,12 +484,12 @@
484	484
485	485	You've done something very special here, taking advantage of the [[Power Of XWiki>>https://propaganda-tactics.com/xwiki/bin/view/About/The%20Power%20of%20XWiki/]] by using data-driven web pages.
486	486
487		-If you had "gone cheap" and naively created a static HTML (or Wiki) page for each Person, you would have had to "hard-code" the table, containing links to them all. And maintaining that table would be a nightmare, needing to update it each time a new Person is added or each time any of the data that it displays is changed on the other page. In addition, if you wanted to change the look of all those pages, you would likely have to change every one of them (even if they share common CSS).
	487	+If we had "gone cheap" and naively created a static HTML (or Wiki) page for each Person, we would have had to "hard-code" the table, containing links to them all. And maintaining that table would be a nightmare because it would need to be updated each time a new Person is added or each time any of the data that it displays is changed on the other page. With XWiki, whenever we add a new Person instance, it will automatically show up in our table because it's automatically generated. In addition, if we hadn't done it this way and we wanted to change the look of the pages, we would likely have to change every one of them (even if they share common CSS).
488	488
489		-On the other end of the spectrum, if you had decided on a typical three-tier high-end architecture, you'd have hired a whole team or even several teams. A "client" team would build pages using Javascript-plus-some-framework. And a "server" team would handle requests from the client to the server to store and retrieve the data. You'd have a database guy (or whole team) store the data in some relational database. Lots of time and energy would go into defining the (perhaps REST) API that the server provides and the client would use. And lots of effort would go into defining the database schema, database creation, and code (perhaps Hibernate or some other ORM tool) to get the data from the database into the server code and back again. All of this is easily 100x the amount of work that you need by using XWiki and doing what you just did.
	489	+At the other end of the spectrum, suppose we had been willing to spend a lot of time and money and decided on a typical three-tier high-end architecture. We would have to hire a whole team or even several teams. A "client" team would build pages using Javascript-plus-some-framework. And a "server" team would handle requests from the client to the server to store and retrieve the data. We'd have a database guy (or whole team) store the data in some relational database. Lots of time and energy would go into defining the (perhaps REST) API that the server provides and the client would use. And lots of effort would go into defining the database schema, database creation, and code (perhaps Hibernate or some other ORM tool) to get the data from the database into the server code and back again. All of this is perhaps 100x the amount of work needed compared to doing the same thing with XWiki.
490	490
491		-Using XWiki in this way, the pages *are* the database, because they don't contain static HTML - they contain Objects - data. And those pages can be queried easily and flexibly. The client side here written in XWiki syntax, which is simpler than HTML, but you could also use HTML and CSS (and even Javascript) if you need more flexibility. The client also contains some simple Velocity code to do things like produce a table. There is no comparison between the simple Velocity code we've just seen and the equivalent Javascript-plus-the-latest-JS-framework code. And even this Velocity code can often be replaced by something even simpler (like "livetable").
	491	+Using XWiki in this way, the pages *are* the database, because they don't contain static HTML - they contain Objects - data. And those pages can be queried easily and flexibly, just like a relational database. The client side here is written in XWiki syntax, which is simpler than HTML and far simpler than Javascript. But we could also use HTML and CSS (and even Javascript) as needed, if we need more flexibility. The client also contains some simple Velocity code to do things like looping to create the rows in a table. There is no comparison between the simple Velocity code we've just seen and the equivalent Javascript-plus-the-latest-JS-framework code. And even this Velocity code can often be replaced by something even simpler (like "livetable").
492	492
493		-Also note that what you've built is an *application*, not just a wiki. Your client side can get nearly as complex as you want. If you do, someday, want some shiny bells and whistles offered by the latest Javascript+framework, you can incorporate that later without too much pain.
	493	+It should be obvious here that what are building is a full, web-based **application**, not just a wiki. So don't be fooled by the name "XWiki". We are using it as a platform for building applications, like [[CUBA>>https://www.cuba-platform.com/]] but far simpler. Our client side can get nearly as complex as we want. If we do, someday, want some shiny bells and whistles offered by the latest Javascript+framework, we can incorporate that later without too much pain.
494	494
495		-In short, by using XWiki this way, you get nearly the flexibility and maintainability of a full three-tier architecture, while only investing nearly the same small effort needed to build the whole thing in static HTML.
	495	+In short, by using XWiki to build a data-driven application, we get nearly the flexibility and maintainability of a full three-tier architecture, while only investing nearly the same small effort needed to build just the client in static HTML.