Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » EPF » Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID
Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #36623] Mon, 06 August 2007 13:36 Go to next message
Karim Benameur is currently offline Karim BenameurFriend
Messages: 20
Registered: July 2009
Junior Member
Hi all,

I noticed a possible side effect due to the migration to the new EPF 1.2.

Some of the web pages have now have a different naming & ID.

For example for each discipline we provided a direct link to a custom
categorie:

* before 1.2 :
arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
* after 1.2 :
arch_task_container\customcategories\arch_D5639D6C.html

All direct links to these web pages are now broken. They have to be updated.

Seems that it is a very bad idea to use direct links to these web pages
as there is no garantee that the name will not change in the future.
Or may be I missed something ;)

Any ideas concerning a way to have a more stable web page access ?
I was thinking about renaming or have a redirection of some sort ...

May be a publishing option for these pages that will be used externally
can be a possible EPF evolution ?

What are the possible scenario that can lead to a change ?

- Import / export ? Upgrade to a new version ?...


What are the web pages that are impacted ?
- All ?

Sorry for asking all these questions !!!

Best Regards
Re: Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #36962 is a reply to message #36623] Mon, 06 August 2007 20:59 Go to previous messageGo to next message
Peter Haumer is currently offline Peter HaumerFriend
Messages: 228
Registered: July 2009
Senior Member
Yes, it is recommended to always use EPF Composer to create such links (e.g.
by dragging and dropping from the Library or Configuration view) or using
the Add Link dialog. Such links always include a GUID attribute that EPFC
uses to recompute the links and even the link text content inside the <a/>
tag when changes happen (e.g. element has been renamed). Migrating a library
with such links will work completely automatically. This was, of course,
tested with our own OpenUP. Hence, always make sure to include the guid even
when you create image maps.

Peter.



"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f9785g$ufo$1@build.eclipse.org...
> Hi all,
>
> I noticed a possible side effect due to the migration to the new EPF 1.2.
>
> Some of the web pages have now have a different naming & ID.
>
> For example for each discipline we provided a direct link to a custom
> categorie:
>
> * before 1.2 :
> arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
> * after 1.2 :
> arch_task_container\customcategories\arch_D5639D6C.html
>
> All direct links to these web pages are now broken. They have to be
> updated.
>
> Seems that it is a very bad idea to use direct links to these web pages as
> there is no garantee that the name will not change in the future.
> Or may be I missed something ;)
>
> Any ideas concerning a way to have a more stable web page access ?
> I was thinking about renaming or have a redirection of some sort ...
>
> May be a publishing option for these pages that will be used externally
> can be a possible EPF evolution ?
>
> What are the possible scenario that can lead to a change ?
>
> - Import / export ? Upgrade to a new version ?...
>
>
> What are the web pages that are impacted ?
> - All ?
>
> Sorry for asking all these questions !!!
>
> Best Regards
>
Re: Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #36999 is a reply to message #36962] Tue, 07 August 2007 13:19 Go to previous messageGo to next message
Karim Benameur is currently offline Karim BenameurFriend
Messages: 20
Registered: July 2009
Junior Member
Thank you Peter for your answer.

We already do what you recommended for internal links in our library.
The problem is more for links done manually in external web site.


For example, imagine that we have a corporate web site and they provide
links to the architecture discipline in the EPF library published web site.

This link is done manually in the corporate web site and so must be
updated when url changed.

Any ideas to manage these links in external web site ?



Peter Haumer wrote:
> Yes, it is recommended to always use EPF Composer to create such links (e.g.
> by dragging and dropping from the Library or Configuration view) or using
> the Add Link dialog. Such links always include a GUID attribute that EPFC
> uses to recompute the links and even the link text content inside the <a/>
> tag when changes happen (e.g. element has been renamed). Migrating a library
> with such links will work completely automatically. This was, of course,
> tested with our own OpenUP. Hence, always make sure to include the guid even
> when you create image maps.
>
> Peter.
>
>
>
> "K.Benameur" <benameur@freesurf.fr> wrote in message
> news:f9785g$ufo$1@build.eclipse.org...
>> Hi all,
>>
>> I noticed a possible side effect due to the migration to the new EPF 1.2.
>>
>> Some of the web pages have now have a different naming & ID.
>>
>> For example for each discipline we provided a direct link to a custom
>> categorie:
>>
>> * before 1.2 :
>> arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
>> * after 1.2 :
>> arch_task_container\customcategories\arch_D5639D6C.html
>>
>> All direct links to these web pages are now broken. They have to be
>> updated.
>>
>> Seems that it is a very bad idea to use direct links to these web pages as
>> there is no garantee that the name will not change in the future.
>> Or may be I missed something ;)
>>
>> Any ideas concerning a way to have a more stable web page access ?
>> I was thinking about renaming or have a redirection of some sort ...
>>
>> May be a publishing option for these pages that will be used externally
>> can be a possible EPF evolution ?
>>
>> What are the possible scenario that can lead to a change ?
>>
>> - Import / export ? Upgrade to a new version ?...
>>
>>
>> What are the web pages that are impacted ?
>> - All ?
>>
>> Sorry for asking all these questions !!!
>>
>> Best Regards
>>
>
>
Re: Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #37626 is a reply to message #36999] Sun, 12 August 2007 23:44 Go to previous message
Peter Haumer is currently offline Peter HaumerFriend
Messages: 228
Registered: July 2009
Senior Member
Sorry, we can only guarantee link migration within our environment. The
other guarantee is that links won't change when the element changes (and
stays within the same plugin, as the plugin name is part of the url).

This particular change in 1.2 however was done for people like you who want
to link to EPFC generated pages and found that the old link schema produced
too long URLs. This change was done to address this issue. You could
explore, if these external web sites should not also be maintained with EPFC
:-)

Peter.



"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f99rgm$n3q$1@build.eclipse.org...
> Thank you Peter for your answer.
>
> We already do what you recommended for internal links in our library. The
> problem is more for links done manually in external web site.
>
>
> For example, imagine that we have a corporate web site and they provide
> links to the architecture discipline in the EPF library published web
> site.
>
> This link is done manually in the corporate web site and so must be
> updated when url changed.
>
> Any ideas to manage these links in external web site ?
>
>
>
> Peter Haumer wrote:
>> Yes, it is recommended to always use EPF Composer to create such links
>> (e.g. by dragging and dropping from the Library or Configuration view) or
>> using the Add Link dialog. Such links always include a GUID attribute
>> that EPFC uses to recompute the links and even the link text content
>> inside the <a/> tag when changes happen (e.g. element has been renamed).
>> Migrating a library with such links will work completely automatically.
>> This was, of course, tested with our own OpenUP. Hence, always make sure
>> to include the guid even when you create image maps.
>>
>> Peter.
>>
>>
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f9785g$ufo$1@build.eclipse.org...
>>> Hi all,
>>>
>>> I noticed a possible side effect due to the migration to the new EPF
>>> 1.2.
>>>
>>> Some of the web pages have now have a different naming & ID.
>>>
>>> For example for each discipline we provided a direct link to a custom
>>> categorie:
>>>
>>> * before 1.2 :
>>> arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
>>> * after 1.2 :
>>> arch_task_container\customcategories\arch_D5639D6C.html
>>>
>>> All direct links to these web pages are now broken. They have to be
>>> updated.
>>>
>>> Seems that it is a very bad idea to use direct links to these web pages
>>> as there is no garantee that the name will not change in the future.
>>> Or may be I missed something ;)
>>>
>>> Any ideas concerning a way to have a more stable web page access ?
>>> I was thinking about renaming or have a redirection of some sort ...
>>>
>>> May be a publishing option for these pages that will be used externally
>>> can be a possible EPF evolution ?
>>>
>>> What are the possible scenario that can lead to a change ?
>>>
>>> - Import / export ? Upgrade to a new version ?...
>>>
>>>
>>> What are the web pages that are impacted ?
>>> - All ?
>>>
>>> Sorry for asking all these questions !!!
>>>
>>> Best Regards
>>>
>>
Re: Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #581271 is a reply to message #36623] Mon, 06 August 2007 20:59 Go to previous message
Peter Haumer is currently offline Peter HaumerFriend
Messages: 228
Registered: July 2009
Senior Member
Yes, it is recommended to always use EPF Composer to create such links (e.g.
by dragging and dropping from the Library or Configuration view) or using
the Add Link dialog. Such links always include a GUID attribute that EPFC
uses to recompute the links and even the link text content inside the <a/>
tag when changes happen (e.g. element has been renamed). Migrating a library
with such links will work completely automatically. This was, of course,
tested with our own OpenUP. Hence, always make sure to include the guid even
when you create image maps.

Peter.



"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f9785g$ufo$1@build.eclipse.org...
> Hi all,
>
> I noticed a possible side effect due to the migration to the new EPF 1.2.
>
> Some of the web pages have now have a different naming & ID.
>
> For example for each discipline we provided a direct link to a custom
> categorie:
>
> * before 1.2 :
> arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
> * after 1.2 :
> arch_task_container\customcategories\arch_D5639D6C.html
>
> All direct links to these web pages are now broken. They have to be
> updated.
>
> Seems that it is a very bad idea to use direct links to these web pages as
> there is no garantee that the name will not change in the future.
> Or may be I missed something ;)
>
> Any ideas concerning a way to have a more stable web page access ?
> I was thinking about renaming or have a redirection of some sort ...
>
> May be a publishing option for these pages that will be used externally
> can be a possible EPF evolution ?
>
> What are the possible scenario that can lead to a change ?
>
> - Import / export ? Upgrade to a new version ?...
>
>
> What are the web pages that are impacted ?
> - All ?
>
> Sorry for asking all these questions !!!
>
> Best Regards
>
Re: Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #581284 is a reply to message #36962] Tue, 07 August 2007 13:19 Go to previous message
Karim Benameur is currently offline Karim BenameurFriend
Messages: 20
Registered: July 2009
Junior Member
Thank you Peter for your answer.

We already do what you recommended for internal links in our library.
The problem is more for links done manually in external web site.


For example, imagine that we have a corporate web site and they provide
links to the architecture discipline in the EPF library published web site.

This link is done manually in the corporate web site and so must be
updated when url changed.

Any ideas to manage these links in external web site ?



Peter Haumer wrote:
> Yes, it is recommended to always use EPF Composer to create such links (e.g.
> by dragging and dropping from the Library or Configuration view) or using
> the Add Link dialog. Such links always include a GUID attribute that EPFC
> uses to recompute the links and even the link text content inside the <a/>
> tag when changes happen (e.g. element has been renamed). Migrating a library
> with such links will work completely automatically. This was, of course,
> tested with our own OpenUP. Hence, always make sure to include the guid even
> when you create image maps.
>
> Peter.
>
>
>
> "K.Benameur" <benameur@freesurf.fr> wrote in message
> news:f9785g$ufo$1@build.eclipse.org...
>> Hi all,
>>
>> I noticed a possible side effect due to the migration to the new EPF 1.2.
>>
>> Some of the web pages have now have a different naming & ID.
>>
>> For example for each discipline we provided a direct link to a custom
>> categorie:
>>
>> * before 1.2 :
>> arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
>> * after 1.2 :
>> arch_task_container\customcategories\arch_D5639D6C.html
>>
>> All direct links to these web pages are now broken. They have to be
>> updated.
>>
>> Seems that it is a very bad idea to use direct links to these web pages as
>> there is no garantee that the name will not change in the future.
>> Or may be I missed something ;)
>>
>> Any ideas concerning a way to have a more stable web page access ?
>> I was thinking about renaming or have a redirection of some sort ...
>>
>> May be a publishing option for these pages that will be used externally
>> can be a possible EPF evolution ?
>>
>> What are the possible scenario that can lead to a change ?
>>
>> - Import / export ? Upgrade to a new version ?...
>>
>>
>> What are the web pages that are impacted ?
>> - All ?
>>
>> Sorry for asking all these questions !!!
>>
>> Best Regards
>>
>
>
Re: Possible EPF 1.2 side effect on published web site ? different naming convention + change in ID [message #581628 is a reply to message #36999] Sun, 12 August 2007 23:44 Go to previous message
Peter Haumer is currently offline Peter HaumerFriend
Messages: 228
Registered: July 2009
Senior Member
Sorry, we can only guarantee link migration within our environment. The
other guarantee is that links won't change when the element changes (and
stays within the same plugin, as the plugin name is part of the url).

This particular change in 1.2 however was done for people like you who want
to link to EPFC generated pages and found that the old link schema produced
too long URLs. This change was done to address this issue. You could
explore, if these external web sites should not also be maintained with EPFC
:-)

Peter.



"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f99rgm$n3q$1@build.eclipse.org...
> Thank you Peter for your answer.
>
> We already do what you recommended for internal links in our library. The
> problem is more for links done manually in external web site.
>
>
> For example, imagine that we have a corporate web site and they provide
> links to the architecture discipline in the EPF library published web
> site.
>
> This link is done manually in the corporate web site and so must be
> updated when url changed.
>
> Any ideas to manage these links in external web site ?
>
>
>
> Peter Haumer wrote:
>> Yes, it is recommended to always use EPF Composer to create such links
>> (e.g. by dragging and dropping from the Library or Configuration view) or
>> using the Add Link dialog. Such links always include a GUID attribute
>> that EPFC uses to recompute the links and even the link text content
>> inside the <a/> tag when changes happen (e.g. element has been renamed).
>> Migrating a library with such links will work completely automatically.
>> This was, of course, tested with our own OpenUP. Hence, always make sure
>> to include the guid even when you create image maps.
>>
>> Peter.
>>
>>
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f9785g$ufo$1@build.eclipse.org...
>>> Hi all,
>>>
>>> I noticed a possible side effect due to the migration to the new EPF
>>> 1.2.
>>>
>>> Some of the web pages have now have a different naming & ID.
>>>
>>> For example for each discipline we provided a direct link to a custom
>>> categorie:
>>>
>>> * before 1.2 :
>>> arch_task_container\customcategories\arch,_jBFJoCTGEdyJ0P6WN Il8_Q.html
>>> * after 1.2 :
>>> arch_task_container\customcategories\arch_D5639D6C.html
>>>
>>> All direct links to these web pages are now broken. They have to be
>>> updated.
>>>
>>> Seems that it is a very bad idea to use direct links to these web pages
>>> as there is no garantee that the name will not change in the future.
>>> Or may be I missed something ;)
>>>
>>> Any ideas concerning a way to have a more stable web page access ?
>>> I was thinking about renaming or have a redirection of some sort ...
>>>
>>> May be a publishing option for these pages that will be used externally
>>> can be a possible EPF evolution ?
>>>
>>> What are the possible scenario that can lead to a change ?
>>>
>>> - Import / export ? Upgrade to a new version ?...
>>>
>>>
>>> What are the web pages that are impacted ?
>>> - All ?
>>>
>>> Sorry for asking all these questions !!!
>>>
>>> Best Regards
>>>
>>
Previous Topic:extends relation
Next Topic:Questions about the published .war file
Goto Forum:
  


Current Time: Thu Apr 18 02:09:27 GMT 2024

Powered by FUDForum. Page generated in 0.02263 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top