div block ID name collisions with 3rd party libraries

[Ken in Nashua <kc...@live.com>]

Folks,

I am operating a tapestry web app.

I have my own web app specific layout which defines a myriad of DIV blocks that use ID for "header", "content", "page", "main", etc.... and I operate these ID definitions heavily within my own CSS.

But then along comes a third party library that promotes usage of their component implementations. But I dont know what they are operating for DIV block ID names. I guess I was able to get the source code I could see.

Lets just say a component library decides to release a dozen components while operating DIV blocks and coincidentally decides to use the ID's for the DIV's "header", "content", "page", "main", etc.... and they also decide to operate these ID definitions heavily within their own CSS.

Is there going to be a problem here ?
Specifically collision ?

Can anyone comment on this ?

Should web app developers be appending the two letters "My" in front of their DIV block ID's if such a component library existed  and does operate ID's for the DIV's "header", "content", "page", "main", etc.... and they
 also decide to operate these ID definitions heavily within their own 
CSS.

Thanks for your input to this subject


 		 	   		  

Re: div block ID name collisions with 3rd party libraries

[Lance Java <la...@googlemail.com>]

Most tapestry components take the approach of using the "id" parameter (not
to be confused with t:id) if one is provided. If an "id" is not provided, a
clientId is generated which is guaranteed not to clash with other id's on
the page.

public class MyComponent implements ClientElement {
   @Environmental
   private JavaScriptSupport jss;

   @Parameter(name = "id", defaultPrefix = BindingConstants.LITERAL)
   private String idParameter;

   @Inject
   private ComponentResources resources;

   void beginRender(MarkupWriter writer) {
      clientId = resources.isBound("id") ? idParameter :
jss.allocateClientId(resources);
      writer.element("div", "id", clientId);
      ...
   }

   @Override
   public String getClientId() {
      return clientId;
   }
}

RE: div block ID name collisions with 3rd party libraries

[Lance Java <la...@googlemail.com>]

It's invalid html to have two elements with the same id so it will need to
be fixed.

Have you considered styling your CSS by "class" instead of by "id"?

Re: div block ID name collisions with 3rd party libraries

[Howard Lewis Ship <hl...@gmail.com>]

Relying on CSS that uses ids, rather than classes, will give you all kinds
of issues integrating it all together. It may render faster on the client,
I don't know.

It's possible to hook into Tapestry and "pre-register" all those ids that
can cause conflicts. Tapestry will then not use them, and will dynamically
allocate different ids; i.e., "header_0" instead of "header".

On Fri, Apr 26, 2013 at 10:20 AM, Lance Java <la...@googlemail.com>wrote:

> I suggest that component authors use the code I gave you. I also suggest to
> style by class instead of by id since the clientId should be a dynamic,
> runtime value that is not known at build time.
>
> If components have a static clientId, they can not (legally) be used in a
> loop.
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

RE: div block ID name collisions with 3rd party libraries

[Lance Java <la...@googlemail.com>]

I suggest that component authors use the code I gave you. I also suggest to
style by class instead of by id since the clientId should be a dynamic,
runtime value that is not known at build time.

If components have a static clientId, they can not (legally) be used in a
loop.

RE: div block ID name collisions with 3rd party libraries

[Ken in Nashua <kc...@live.com>]

Thanks Lance,

These options are all great... helpful. I am interfacing with the author and trying to communicate what I have identified is a show stopper for the users of their library.

I think some rules of thumb need to be agreed upon especially with regard to owness.

So it should really be up to the component library author to self contain and secure it's library from coming apart at the seams no matter who's camp it lands in. 

Any best practice recommendations for component library developers would be helpful. It seems like a wide open issue. I wonder if tapestry recommends or advises special attention to this.

But you have been a tremendous help so far.

Thanks

I am in a holding pattern wondering whether I should modify my webapp code or wait til something changes for the component library author.

- cheers

Ken
 		 	   		  

RE: div block ID name collisions with 3rd party libraries

[Ken in Nashua <kc...@live.com>]

Thanks Lance,

Thats helpful information.

I have a case where explicit raw usage of those ID's header, nav, main... are being used right within a CSS file or even in explicit style .

So my layout is being blown off the map... (oops page).

I still am wondering what solution I should impose.

Thanks
Ken