Which Menu / links design approach to choose

Which Menu / links design approach to choose

  
Menu / Links Approach
 
Links can be declared using a 
reference.
Advantage
-  The link is always correct because this is checked design-time
 
Disadvantage
-  If they are declared as a reference to another E-space, the menu would need a recompile 
   every time the consumed E-space where the link referring to is (re)published.
   This will take a very long time if a lot of E-spaces are referenced in the Menu
 
 
Links can be declared using a static 
link.
Advantage
 
Disadvantage
- The links will not work correctly with the Public Area and Private Area
  (Testing will ALWAYS need to be done in the Public Area)
 
Links can be declared using a dynamic 
link.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
 
Disadvantage
 
 
Links can be declared using a dynamic 
link retrieved from a static table.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
 
Disadvantage
- Links can NOT be modified at runtime
 
Links can be declared using a dynamic 
link retrieved from a table.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
- Links can be modified at runtime (In case a typo has been made)
- Compiling can be faster
 
Disadvantage
- No design-time link verification (you don't know if a typo has been made)
Menu / Links Approach
 
Links can be declared using a 
reference.
Advantage
-  The link is always correct because this is checked design-time
 
Disadvantage
-  If they are declared as a reference to another E-space, the menu would need a recompile 
   every time the consumed E-space where the link referring to is (re)published.
   This will take a very long time if a lot of E-spaces are referenced in the Menu
 
 
Links can be declared using a static 
link.
Advantage
 
Disadvantage
- The links will not work correctly with the Public Area and Private Area
  (Testing will ALWAYS need to be done in the Public Area)
 
Links can be declared using a dynamic 
link.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
 
Disadvantage
 
 
Links can be declared using a dynamic 
link retrieved from a static table.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
 
Disadvantage
- Links can NOT be modified at runtime
 
Links can be declared using a dynamic 
link retrieved from a table.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
- Links can be modified at runtime (In case a typo has been made)
- Compiling can be faster
 
Disadvantage
- No design-time link verification (you don't know if a typo has been made)
Menu / Links Approach
 
Links can be declared using a 
reference.
Advantage
-  The link is always correct because this is checked design-time
 
Disadvantage
-  If they are declared as a reference to another E-space, the menu would need a recompile 
   every time the consumed E-space where the link referring to is (re)published.
   This will take a very long time if a lot of E-spaces are referenced in the Menu
 
 
Links can be declared using a static 
link.
Advantage
 
Disadvantage
- The links will not work correctly with the Public Area and Private Area
  (Testing will ALWAYS need to be done in the Public Area)
 
Links can be declared using a dynamic 
link.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
 
Disadvantage
 
 
Links can be declared using a dynamic 
link retrieved from a static table.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
 
Disadvantage
- Links can NOT be modified at runtime
 
Links can be declared using a dynamic 
link retrieved from a table.
Advantage
- The links will work correctly with the Public Area and Private Area, if a special function is used
- Links can be modified at runtime (In case a typo has been made)
- Compiling can be faster
 
Disadvantage
- No design-time link verification (you don't know if a typo hasn made)
Hi Guy's,

I'm working on a set of 14 E-spaces that is growing pretty quick and I'm running into some
publish speed issues and constant situations where I need to rebuild over half of all E-spaces when refactoring or when adding menu Items.

I have a correct structure, without cross references but I'm having issues selecting the right way
to link to other E-spaces e.g. in the Menu and in popup's that refer to other E-spaces.

I know combining the E-spaces would solve some issues; but that would dramatically increase the publish / debug time.
 
1. Links can be declared using a reference. (Default way of 'linking')
Advantage
+ The link is always correct because this is verified at design-time, which is a huge advantage
+ The links will work correctly with the Public Area and Private Area
 
Disadvantage
-  If they are declared as a reference to another E-space, the menu would need a (re)publish 
   every time the consumed E-space where the link referring to is (re)published.
   This will take a very long time if a lot of E-spaces are referenced in the Menu
- Cross references (forcing a creation of a lot of OSP's for each 'level' time you want to publish
  or being lazy forcing you to publish the whole E-space list concerned)
 
2. Links can be declared using a static link.
Advantage
+ The E-space the link is pointing doesn't need to be referenced
+ Because the 'consumed' E-space doesn't need to be referenced a modification of that E-space has
  no 'direct' impact on the consistent state of the consumer  In other words;
  there is no Cross reference and there is no need to (re)publish it's consumers.
  Compiling can be done faster in case of a lot of E-spaces
 
Disadvantage
- The links will not work correctly with the Public Area and Private Area
  (Testing will ALWAYS need to be done in the Public Area)
- Links are not verified at designtime and a republish is needed if the link needs to be modified
  (you don't know if a typo has been made; and couldn't correct it quickly if noticed)
 
3. Links can be declared using a dynamic link.
Advantage
+ The links will work correctly with the Public Area and Private Area, if a special function is used
+ Because the 'consumed' E-space doesn't need to be referenced a modification of that E-space has 
  no 'direct' impact on the consistent state of the consumer  In other words; 
  there is no Cross reference and there is no need to (re)publish it's consumers.
  Compiling can be done faster in case of a lot of E-spaces
 
Disadvantage
- Links can NOT be modified at runtime
- Links are not verified at designtime and a republish is needed if the link needs to be modified
  (you don't know if a typo has been made; and couldn't correct it quickly if noticed)
 
4. Links can be declared using a dynamic link retrieved from a static table.
Advantage
+ The links will work correctly with the Public Area and Private Area, if a special function is used
+ Because the 'consumed' E-space doesn't need to be referenced a modification of that E-space has 
  no 'direct' impact on the consistent state of the consumer  In other words; 
  there is no Cross reference and there is no need to (re)publish it's consumers.
  Compiling can be done faster in case of a lot of E-spaces
 
Disadvantage
- Links can NOT be modified at runtime
- Links are not verified at designtime and a republish is needed if the link needs to be modified
  (you don't know if a typo has been made; and couldn't correct it quickly if noticed)
 
5. Links can be declared using a dynamic link retrieved through an action from a table.
Advantage
+ The links will work correctly with the Public Area and Private Area, if a special function is used
+ Because the 'consumed' E-space doesn't need to be referenced a modification of that E-space has 
  no 'direct' impact on the consistent state of the consumer  In other words; 
  there is no Cross reference and there is no need to (re)publish it's consumers.
  Compiling can be done faster in case of a lot of E-spaces
+ Links can be modified at runtime (In case a typo has been made)
+ It's might be possible to let an exception send an E-mail notification if a link receives a 404 error
 
Disadvantage
- No design-time link verification (you don't know if a typo has been made)


Please let me know which approach you would take / which is recommended.
Hi Eric,

That is an awesome drilldown of the issue!

From my experience I tend to use 5 for menus (retrieving the links from a table), and for other links 1 (reference) or 3 (dynamic link, with site properties) depending if the eSpace is already referenced or not . Although I have not used it, solution 4 (static entities) also sounds like a good idea.
 
Cheers,
Tiago Simões

PS: The special function you are mentioning is AddPersonalAreaToURLPath(), right?
Hi Tiago,

Thanks for your reply.
This is indeed the function I meant (and currently am using).
Option 5 currently is my preferred one although this is missing the verification at design time.

This verification could be created manually by using the HttpGet command on all references stored in the table.
That could be moved to either a timer or a manual action.

This method would actually load the pages for you and with making the connection force ASP.net to create a 'cached' version of that page.
(Saves you some waiting time when clicking it)
It would be nice if the method retrieving the URL from the database would be able to detect a broken link and E-mail the maintainer.

This 'workaround' might mean you'd need to use some kind global user permission setup to access the page which could be interpreted as a security risk.

I'm actually hoping for a better / more integrated approach of this in the future.
Hi Eric,

My prefered design for menus is having them strongly typed in a couple of static entities, and linking to the effective screens using strong references for the simple reason it is the design that avoids most design time errors.

I am aware of the impact this has on change propagation when you have multiple large espaces, but publishing a solution should be enough.

"This will take a very long time if a lot of E-spaces are referenced in the Menu"

Can you be more specific? How long?

Anyway, if you really want to use links in the database (either static or dynamic), you may want to check the new system entities Espace_Screen and Espace_Screen_Param to validate you links. They were introduced in 5.1. This way you could hide your invalid menu entries at runtime.

Cheers,
Lúcio

#5 would be the best option here using a dynamic link retrieved through an action from a table.

Will the database contain links to externalurl as well? (not just links from eSpace to eSpace?)
 
You can have a timer to run X circles per day to check and flag a link is good or bad.
 
If it returns a 200 ok status code or returns a response within X amount of time, then update your database accordingly.
 
However it doesn't tell you if the link is valid or invalid, its still going to tell you your linked page is ok even after it has been hijacked.

p.s you can use windows task scheduler for your timer and make it open the  webscreen page that contains preparation actions to checks if your  links are ok.
Hi Guys,

Thanks for your replies!

I think I'll go with option 5, using the kind of 'check' option Robert proposes.
I'm also hoping this could be a point of attention for R&D.

Cheers!

Eric
> "This will take a very long time if a lot of E-spaces are referenced in the Menu"
> Can you be more specific? How long?

Dear Lucio,

A republish of my application currently takes 13 minutes and 41 seconds.
This whereas most of the compilation of E-spaces is skipped because no changes were made to them.
@Eric

 Option #6: Build a central resource management application, to manage your platform resources(locate: "page, media and stylesheet").

Basic Example: Download 

To locate a resource from your eSpace application you would use it like this

http://<hostname>/ResourceCenter/Get.aspx?Page=<Static Name Id >
http://<hostname>/ResourceCenter/Get.aspx?Media=<Static Name Id >
http://<hostname>/ResourceCenter/Get.aspx?Stylesheet=<Static Name Id >

Note: you might want to add a unique index for the RESOURCE.name attribute and add other actions you feel necessary.
Good thinking Robert, thanks!