8000 moved most static assets directly into the templates by fabpot · Pull Request #6006 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

moved most static assets directly into the templates #6006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 14, 2012

Conversation

fabpot
Copy link
Member
@fabpot fabpot commented Nov 13, 2012

This has been done for several reasons:

  • for consistency with the way we already manage the WDT and the
    profiler icons;
  • it makes the Exception independent from the location of the assets
    (and from the asset() function)
  • this is the second step to make the WebProfiler useable outside the
    full-stack framework

see dbcd171

@stof
Copy link
Member
stof commented Nov 13, 2012

the images blue_picto_more and blue_picto_less are also used in DoctrineBundle (and probably in JMSDebuggingBundle but I haven't checked). Could you submit a PR inlining the images too before removing them ?

@fabpot
Copy link
Member Author
fabpot commented Nov 13, 2012

Any image useful for other bundles should not be deleted. So, if DoctrineBundle is using the blue_pico_* images, I'm going to revert their deletion.

@schmittjoh
Copy link
Contributor

I'm using them in two bundles, JMSDebuggingBundle and JMSJobQueueBundle (same for the exception related templates).

@dlsniper
Copy link
Contributor

Wouldn't it be better to have the encoded icons in a separate CSS file as different classes/background images?

This has been done for several reasons:

 * for consistency with the way we already manage the WDT and the
   profiler icons;
 * it makes the Exception independent from the location of the assets
   (and from the asset() function)
 * this is the second step to make the WebProfiler useable outside the
   full-stack framework

see dbcd171
@fabpot
Copy link
Member Author
fabpot commented Nov 14, 2012

ok, I've reverted the removal of the images that might be useful in third-party bundles.

fabpot added a commit that referenced this pull request Nov 14, 2012
This PR was merged into the master branch.

Commits
-------

9f1cd84 moved most static assets directly into the templates

Discussion
----------

moved most static assets directly into the templates

This has been done for several reasons:

 * for consistency with the way we already manage the WDT and the
   profiler icons;
 * it makes the Exception independent from the location of the assets
   (and from the asset() function)
 * this is the second step to make the WebProfiler useable outside the
   full-stack framework

see dbcd171

---------------------------------------------------------------------------

by stof at 2012-11-13T17:52:39Z

the images blue_picto_more and blue_picto_less are also used in DoctrineBundle (and probably in JMSDebuggingBundle but I haven't checked). Could you submit a PR inlining the images too before removing them ?

---------------------------------------------------------------------------

by fabpot at 2012-11-13T18:02:18Z

Any image useful for other bundles should not be deleted. So, if DoctrineBundle is using the blue_pico_* images, I'm going to revert their deletion.

---------------------------------------------------------------------------

by schmittjoh at 2012-11-13T18:07:02Z

I'm using them in two bundles, JMSDebuggingBundle and JMSJobQueueBundle (same for the exception related templates).

---------------------------------------------------------------------------

by dlsniper at 2012-11-13T22:22:29Z

Wouldn't it be better to have the encoded icons in a separate CSS file as different classes/background images?

---------------------------------------------------------------------------

by fabpot at 2012-11-14T11:28:24Z

ok, I've reverted the removal of the images that might be useful in third-party bundles.
@fabpot fabpot closed this Nov 14, 2012
@fabpot fabpot merged commit 9f1cd84 into symfony:master Nov 14, 2012
ostrolucky pushed a commit to ostrolucky/symfony that referenced this pull request Mar 25, 2018
This PR was merged into the master branch.

Commits
-------

9f1cd84 moved most static assets directly into the templates

Discussion
----------

moved most static assets directly into the templates

This has been done for several reasons:

 * for consistency with the way we already manage the WDT and the
   profiler icons;
 * it makes the Exception independent from the location of the assets
   (and from the asset() function)
 * this is the second step to make the WebProfiler useable outside the
   full-stack framework

see dbcd171

---------------------------------------------------------------------------

by stof at 2012-11-13T17:52:39Z

the images blue_picto_more and blue_picto_less are also used in DoctrineBundle (and probably in JMSDebuggingBundle but I haven't checked). Could you submit a PR inlining the images too before removing them ?

---------------------------------------------------------------------------

by fabpot at 2012-11-13T18:02:18Z

Any image useful for other bundles should not be deleted. So, if DoctrineBundle is using the blue_pico_* images, I'm going to revert their deletion.

---------------------------------------------------------------------------

by schmittjoh at 2012-11-13T18:07:02Z

I'm using them in two bundles, JMSDebuggingBundle and JMSJobQueueBundle (same for the exception related templates).

---------------------------------------------------------------------------

by dlsniper at 2012-11-13T22:22:29Z

Wouldn't it be better to have the encoded icons in a separate CSS file as different classes/background images?

---------------------------------------------------------------------------

by fabpot at 2012-11-14T11:28:24Z

ok, I've reverted the removal of the images that might be useful in third-party bundles.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0