Reparsing groups ( add flag in configuration options to parse groups again)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. This happens when there is EL inside of CSS and groups have groups references
2. If there is a a.css(has EL) and is used in group1 and group1 is referenced 
in group2.
3. When we try and use group2 it uses the already parsed a.css from group1 
which is not what we want. WRO can have a configuration option where we can 
specify it to reparse any groups if they are referenced. 
4. So if we request for group2 it will reparse group1 again and evaluate the EL 
in a.css
5. This can help us keep the configuration to a minimum and use inherited 
groups.

What is the expected output? What do you see instead?
We see already parsed a.css but what we want is for a.css to be parsed again.

What version of the product are you using? On what operating system?
1.4.8

Please provide any additional information below.

Original issue reported on code.google.com by shantanu...@ihg.com on 28 Aug 2012 at 4:11

[GoogleCodeExporter]

I don't really understand the problem. Probably a simple example would make it 
more clear.

Also, I think you misunderstand what the group references means. 
When you have a group which references another group, it has absolutely no 
special handling. The effect is the same as copy+paste-ing the resources from 
one group to another. It is just a convenient way to define a model. So, if you 
have:

group1 {
  js(/r1.js)
  js(/r2.js)
  group2()
}
group2 {
  js(/r3.js)
  js(/r4.js)
}

The outcome is identical if you would have the following model:

group1 {
  js(/r1.js)
  js(/r2.js)
  js(/r3.js)
  js(/r4.js)
}
group2 {
  js(/r3.js)
  js(/r4.js)
}

I think it is important to describe what do you mean by parse and reparse. 
Having an EL inside CSS is an unimportant detail and shouldn't make any 
difference. 

Maybe I didn't understand well your problem.

Original comment by alex.obj...@gmail.com on 28 Aug 2012 at 5:56

[GoogleCodeExporter]

I'll try and explain my problem:

Say we have to groups:
group1 {
  js(/r1.js)
  js(/r2.js)
  group2()
}
group2 {
  js(/r3.js)
  js(/r4.js)
}

If the user first requests for "group2":
1. wro will parse the r3 and r4 ( and also evaluate any EL inside it)
2. render the group back to the user.
3. Cache group2 for any future requests.

If the user then requests for group1:
1. wro will parse r1 and r2 and USE the "cached" group2.
(This is the behavior that we are seeing in our systems)
And to solve this we have to define the groups as:
group1 {
  js(/r1.js)
  js(/r2.js)
  js(/r3.js)
  js(/r4.js)
}
group2 {
  js(/r3.js)
  js(/r4.js)
}

Which is blowing up the configurations and doesn't let us inherited groups 
ideally.

Original comment by shantanu...@ihg.com on 28 Aug 2012 at 6:07

[GoogleCodeExporter]

That is not quite true. 
When group1 is requested, it caches the result of processing all resources 
contained in that group. It doesn't cache the result produced by group2. 
Probably the problem you have is caused by something different. Can you bring 
some evidence or show more examples of your problem?

Original comment by alex.obj...@gmail.com on 28 Aug 2012 at 6:13

[GoogleCodeExporter]

Closing the issue with INVALID status. 
Feel free to reopen it if you have more details.

Original comment by alex.obj...@gmail.com on 30 Aug 2012 at 11:47

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 30 Aug 2012 at 11:48

• Changed state: Invalid