Which Menu / links design approach to choose

Back to Forums

Eric Oud Ammerveld

Question

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.

30 Jun 2010

Tiago Simões

Staff

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?

30 Jun 2010

Eric Oud Ammerveld

Hi Tiago,

Thanks for your reply.
This is indeed the function I meant (and currently am using).

30 Jun 2010

Eric Oud Ammerveld

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.

30 Jun 2010

Lúcio Ferrão

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

30 Jun 2010

Robert Chanphakeo

#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.

03 Jul 2010

Eric Oud Ammerveld

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

05 Jul 2010

Eric Oud Ammerveld

> "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.

05 Jul 2010

Robert Chanphakeo

@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

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

https://<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.

31 Jul 2010

Eric Oud Ammerveld

Good thinking Robert, thanks!

02 Aug 2010

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.

See the full guidelines