Differences

This shows you the differences between two versions of the page.

--- docs:webapps [2008-08-02 22:43] – grizz
+++ docs:webapps [2008-08-04 16:44] (current) – typo grizz
@@ Line 1: / Line 1: @@
 /* page was renamed from Documentation/Webapps */
-why webapps is better than apache_config_* macros
-. unified structure. all configs are in /etc/webapps/$webapp admin is not confused, where's the config for app foo
-. simplier no fancy rpm macro options, due layout being unified in front
+====== Why webapps is better than apache_config_* macros ======
-. can have multiple webapps configuration per .spec the limitation is because symlink used is %{name} which you can't override in spec. this is not hard to overcome, but it still exists.
-in other words You can easily manage multiple instances of a given webapp, by simply adding another link to.
+===== 1. Unified structure. All configs are in /etc/webapps/$webapp =====
+Admin is not confused, where's the config for app foo.
-. no confusing numbers Using config load order is not needed anymore. Order in which webapps are loaded does not matter.
-. there's cli There's a cli program called 'webapp' which you can use to view add and remove webapp links
-. separate apache configs apache 1.3 and apache 2.x can have different configs, so you can create different setup for different vhosts. this is not actually a limitation.
+===== 2. Simplier =====
+No fancy rpm macro options, due layout being unified in front.
-. free for other webservers it is open to add any webserver. lighttpd has hooks but nobody has made any config.
-. you can have "modules" you can have a webapp to have subwebapp. say horde is the main package, and horde/imp is horde module. then the webapp name for horde-imp is "horde/imp". the way the config symlinks are created module webapp configs are loaded before master. this allows you define /horde alias in main application and /horde/imp in sub application. it's transparent, you don't even have to think about that.
+===== 3. Can have multiple webapps configuration per .spec =====
+The limitation is because symlink used is %{name} which you can't override in spec. This is not hard to overcome, but it still exists.
+In other words You can easily manage multiple instances of a given webapp, by simply adding another link to.
+===== 4. No confusing numbers =====
+Using config load order is not needed anymore. Order in which webapps are loaded does not matter.
+===== 5. there's cli =====
+There's a cli program called 'webapp' which you can use to view add and remove webapp links.
+===== 6. Separate apache configs =====
+Apache 1.3 and apache 2.x can have different configs, so you can create different setup for different vhosts. This is not actually a limitation.
+===== 7. Free for other webservers =====
+It is open to add any webserver. lighttpd has hooks but nobody has made any config.
+===== 8. You can have "modules" =====
+You can have a webapp to have subwebapp. Say horde is the main package, and horde/imp is horde module. Then the webapp name for horde-imp is "horde/imp". The way the config symlinks are created module webapp configs are loaded before master. This allows you define /horde alias in main application and /horde/imp in sub application. It's transparent, you don't even have to think about that.
@@ Line 26: / Line 51: @@
 lrwxrwxrwx  /etc/httpd/webapps.d/drupal.conf -> ../../../etc/webapps/drupal/httpd.conf
 </file>
-. webapps do not have to be rpm packages in case you have application that's not rpm package, you can achieve similiar effect. as the program to register is available outside rpm macros.
- [[:CategoryUpdateNeeded|CategoryUpdateNeeded]]
+===== 9. Webapps do not have to be rpm packages =====
+In case you have application that's not rpm package, you can achieve similiar effect. As the program to register is available outside rpm macros.