Introduce different addresses for compressed resources & images loading

6 views
Skip to first unread message

Alexander Obuhovich

unread,
Jul 2, 2010, 7:20:04 AM7/2/10
to In-Portal Development
I propose to introduce different addresses for compressed resources & images loading. Both settings will be optional.

This means, that all resources, that were uploaded from administrative console will be fetched from different url, which points to same DocumentRoot.
Same for compressed css/js, but url can be different.

For example:
This approach ensures faster site load time, then usual, because images and compressed resources will be cached on fast webserver.


--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

Dmitry Andrejev

unread,
Jul 2, 2010, 4:04:23 PM7/2/10
to in-por...@googlegroups.com
Hi Alex,


I am glad that you have raised this. Actually I have mentioned that before - it's quite critical on big projects.

There is 1 think we should count in - Site Domains. We should be able to specify this on Site Domain level if needed. Basically I suggest to have Common settings so this can be working without site domains and then add the same fields on Site Domain level so when it's needed it would work specifically with ones.


What you think?


DA.

Phil -- wbtc.fr --

unread,
Jul 2, 2010, 4:08:03 PM7/2/10
to in-por...@googlegroups.com
Good idea Alex!

2010/7/2 Dmitry Andrejev <dand...@gmail.com>

Alexander Obuhovich

unread,
Jul 3, 2010, 7:32:50 AM7/3/10
to in-por...@googlegroups.com
Also we could load jquery from google code repository. Because of most sites using jquery does that too, then jquery will cached by browser and available for In-Portal already.

Alexander Obuhovich

unread,
Jul 3, 2010, 10:17:04 AM7/3/10
to in-por...@googlegroups.com
Also we could think of site domain based configuration variables. For example in "Configuration -> Website -> Output" section we could have dropdown (in blue bar on top) with all site domains listed and "Common" as first entry, like this:
  • common
  • domainA.com
  • domainB.com

This way administrator could have any configuration variable to be domain-specific. When there is no value, then common value is used.

I see this as separate column with value in ConfigurationValues table, like we have for languages. For example:
  • VariableValue
  • sd1_VariableValue
  • sd2_VariableValue
and so on.

We then will select values like this:

SELECT IF(sd2_VariableValue IS NULL, VariableValue, sd2_VariableValue)
FROM ConfigurationValues
WHERE VariableName = 'Site_Name';

Cases, when we deliberately want site domain configuration variable value to empty are not supported in this scheme.

Dmitry Andrejev

unread,
Jul 5, 2010, 1:56:00 AM7/5/10
to in-por...@googlegroups.com
Hi Alex,


Sorry did fully get your idea. Would you please clarify more.

Does it mean I can have different settings of these variables for any of Site Domains?



DA.

Alexander Obuhovich

unread,
Jul 5, 2010, 2:55:37 AM7/5/10
to in-por...@googlegroups.com
Yes, it's like language selector in top frame, but it will be site domain selector in configuration sections.

Phil -- wbtc.fr --

unread,
Jul 5, 2010, 5:03:52 AM7/5/10
to in-por...@googlegroups.com
really good idea. + need to add "all site" value in drop down :)

2010/7/5 Alexander Obuhovich <aik....@gmail.com>

Alexander Obuhovich

unread,
Jul 5, 2010, 8:51:24 AM7/5/10
to in-por...@googlegroups.com
I've added that value too in my original post. It was named "common" in my original post.

What about "Cases, when we deliberately want site domain configuration variable value to empty are not supported in this scheme." then?

Are all ok with such limitation to my scheme?

Dmitry Andrejev

unread,
Jul 5, 2010, 11:13:06 AM7/5/10
to in-por...@googlegroups.com
Thanks for clarifying Alex - I agree with your idea too.

I would call your "common" as ":: default :: " or something so it's stands out more.

Are you able to document all this together in a task?


DA.

Alexander Obuhovich

unread,
Aug 31, 2010, 2:46:37 PM8/31/10
to in-por...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages