|
|
|
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 |
Peter Haumer 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 #581628 is a reply to message #36999] |
Sun, 12 August 2007 23:44 |
Peter Haumer 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
>>>
>>
|
|
|
Powered by
FUDForum. Page generated in 0.04955 seconds