Defining app root

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Defining app root

Jussi Hirvi-2
This is an old question for me, and I still have not found a satisfying
answer. This is L8.6, btw.

Sometimes my app is accessed with http://example.com, and sometimes
https://secure.myserver.com/example.

To get all the includes working I always use relative links, for example
        include('inc/defaults.inc');

However, this is not fully satisfying, because some include files should
be accessible from several directory hierarchy levels, and if these
include files in turn have include statements, they will be broken.

WordPress currently uses a solution which seems elegant. In index.php
(app root) they have
require( dirname( __FILE__ ) . '/wp-blog-header.php' );

Where dirname( __FILE__ ) seems to return the parent directory of the
current file (though from the system root, for example
/var/www/example.com/www-site/testdir). If this statement is placed in
an include file, it returns the parent directory of that included file,
NOT of the file that is calling the included file.

Lasso has include_currentpath that could be tailored for this use, but
include_currentpath includes the file name, which should be removed
first using a ctag.

I have also toyed with a variable "approot", but it's clumsy because it
should be defined separately for each "parent file" (files that are
called directly on the browser).

How have you guys solved this problem?

- Jussi

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Defining app root

Jussi Hirvi-2
Ok, now I have a working solution, though I would like it to be a little
tidier.

This is my new tag:

define_tag('mydir',-namespace='MO',
        -required='path',-type='string',
        -encodeNone);
   // to be used in include tags
   local('out') = #path -> split('/');
   #out -> last = '';
   return(#out -> join('/'));
/define_tag;

And here is an include tag in my file /custom/preform/myfile.inc, which
points to /inc/my.inc:
include(MO_mydir(include_currentpath) + '../../inc/my.inc');

Now the include works, no matter what page is called on the browser.
Specifically, it works in both of these cases:
        http://example.com/myfile.html
        https://secure.webhotel.com/example.com/myfile.html

- Jussi


On 19.1.2015 12.48, Jussi Hirvi wrote:

> This is an old question for me, and I still have not found a satisfying
> answer. This is L8.6, btw.
>
> Sometimes my app is accessed with http://example.com, and sometimes
> https://secure.myserver.com/example.
>
> To get all the includes working I always use relative links, for example
>      include('inc/defaults.inc');
>
> However, this is not fully satisfying, because some include files should
> be accessible from several directory hierarchy levels, and if these
> include files in turn have include statements, they will be broken.
>
> WordPress currently uses a solution which seems elegant. In index.php
> (app root) they have
> require( dirname( __FILE__ ) . '/wp-blog-header.php' );
>
> Where dirname( __FILE__ ) seems to return the parent directory of the
> current file (though from the system root, for example
> /var/www/example.com/www-site/testdir). If this statement is placed in
> an include file, it returns the parent directory of that included file,
> NOT of the file that is calling the included file.
>
> Lasso has include_currentpath that could be tailored for this use, but
> include_currentpath includes the file name, which should be removed
> first using a ctag.
>
> I have also toyed with a variable "approot", but it's clumsy because it
> should be defined separately for each "parent file" (files that are
> called directly on the browser).
>
> How have you guys solved this problem?
>
> - Jussi

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Defining app root

Ke Carlton-3
In reply to this post by Jussi Hirvi-2
Lasso 9 has: include_path —
http://www.lassosoft.com/lassoDocs/languageReference/obj/include_path

Although depending on the situation I may hard code the app root:

define app_root => '//path/to/app/root'


It would be great if every body who was able took a shot at upgrading to
Lasso 9 — the benefits really do out weigh the initial investment.

Ke

On 19 January 2015 at 23:48, Jussi Hirvi <[hidden email]> wrote:

> This is an old question for me, and I still have not found a satisfying
> answer. This is L8.6, btw.
>
> Sometimes my app is accessed with http://example.com, and sometimes
> https://secure.myserver.com/example.
>
> To get all the includes working I always use relative links, for example
>         include('inc/defaults.inc');
>
> However, this is not fully satisfying, because some include files should
> be accessible from several directory hierarchy levels, and if these include
> files in turn have include statements, they will be broken.
>
> WordPress currently uses a solution which seems elegant. In index.php (app
> root) they have
> require( dirname( __FILE__ ) . '/wp-blog-header.php' );
>
> Where dirname( __FILE__ ) seems to return the parent directory of the
> current file (though from the system root, for example /var/www/
> example.com/www-site/testdir). If this statement is placed in an include
> file, it returns the parent directory of that included file, NOT of the
> file that is calling the included file.
>
> Lasso has include_currentpath that could be tailored for this use, but
> include_currentpath includes the file name, which should be removed first
> using a ctag.
>
> I have also toyed with a variable "approot", but it's clumsy because it
> should be defined separately for each "parent file" (files that are called
> directly on the browser).
>
> How have you guys solved this problem?
>
> - Jussi
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>
>

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Defining app root

decorior
Not sure if this helps but we have a tag called setrecursion (below for 9, we have an 8 version also)

Then we always use the include as if it is in the root

e.g. include(setrecursion + `lasso/doit.lasso`)

This has actually worked very well for us.


<?lassoscript

define setrecursion() => {
local(value) = Response_FilePath->split(`/`);
        match(#value->size)=>{
                case(2);
                        return(``);
                case(3);
                        return(`../`);
                case(4);
                        return(`../../`);
                case(5);
                        return(`../../../`);
                case(6);
                        return(`../../../../`);
        }
}
?>



> On Jan 20, 2015, at 2:52 PM, Ke Carlton <[hidden email]> wrote:
>
> Lasso 9 has: include_path —
> http://www.lassosoft.com/lassoDocs/languageReference/obj/include_path
>
> Although depending on the situation I may hard code the app root:
>
> define app_root => '//path/to/app/root'
>
>
> It would be great if every body who was able took a shot at upgrading to
> Lasso 9 — the benefits really do out weigh the initial investment.
>
> Ke
>
> On 19 January 2015 at 23:48, Jussi Hirvi <[hidden email]> wrote:
>
>> This is an old question for me, and I still have not found a satisfying
>> answer. This is L8.6, btw.
>>
>> Sometimes my app is accessed with http://example.com, and sometimes
>> https://secure.myserver.com/example.
>>
>> To get all the includes working I always use relative links, for example
>>        include('inc/defaults.inc');
>>
>> However, this is not fully satisfying, because some include files should
>> be accessible from several directory hierarchy levels, and if these include
>> files in turn have include statements, they will be broken.
>>
>> WordPress currently uses a solution which seems elegant. In index.php (app
>> root) they have
>> require( dirname( __FILE__ ) . '/wp-blog-header.php' );
>>
>> Where dirname( __FILE__ ) seems to return the parent directory of the
>> current file (though from the system root, for example /var/www/
>> example.com/www-site/testdir). If this statement is placed in an include
>> file, it returns the parent directory of that included file, NOT of the
>> file that is calling the included file.
>>
>> Lasso has include_currentpath that could be tailored for this use, but
>> include_currentpath includes the file name, which should be removed first
>> using a ctag.
>>
>> I have also toyed with a variable "approot", but it's clumsy because it
>> should be defined separately for each "parent file" (files that are called
>> directly on the browser).
>>
>> How have you guys solved this problem?
>>
>> - Jussi
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Defining app root

Jussi Hirvi-2
Ok, looks neat, and without testing I would say that it would work for
me in most cases, except in cases where the app root is called two ways
- for example, I am just developing an app where some pages are served
ssl-encrypted. For those pages the app root is
        https://secure.myserver.fi/mydomain
...and for other pages
        http://mydomain.com

Anyway, I have a working solution now, as I explained in my previous
message. The downside with that is that the actual paths (as seen in the
browser source code for .css, .js paths, etc.) sometimes contain
unneeded back-and-forth movement, for example
/theme/../inc/../inc/my.inc. This happens with longer include chains
(where file a includes file b, b includes c, etc.). But as long as the
links work, I can live with that. :-)

- Jussi


On 21.1.2015 0.00, deco rior wrote:

> Not sure if this helps but we have a tag called setrecursion (below for 9, we have an 8 version also)
>
> Then we always use the include as if it is in the root
>
> e.g. include(setrecursion + `lasso/doit.lasso`)
>
> This has actually worked very well for us.
>
>
> <?lassoscript
>
> define setrecursion() => {
> local(value) = Response_FilePath->split(`/`);
> match(#value->size)=>{
> case(2);
> return(``);
> case(3);
> return(`../`);
> case(4);
> return(`../../`);
> case(5);
> return(`../../../`);
> case(6);
> return(`../../../../`);
> }
> }
> ?>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Defining app root

decorior
Yep,

Actually I generally link shared files via a symbolic link which works great.


> On Jan 21, 2015, at 8:22 AM, Jussi Hirvi <[hidden email]> wrote:
>
> Ok, looks neat, and without testing I would say that it would work for me in most cases, except in cases where the app root is called two ways - for example, I am just developing an app where some pages are served ssl-encrypted. For those pages the app root is
> https://secure.myserver.fi/mydomain
> ...and for other pages
> http://mydomain.com
>
> Anyway, I have a working solution now, as I explained in my previous message. The downside with that is that the actual paths (as seen in the browser source code for .css, .js paths, etc.) sometimes contain unneeded back-and-forth movement, for example /theme/../inc/../inc/my.inc. This happens with longer include chains (where file a includes file b, b includes c, etc.). But as long as the links work, I can live with that. :-)
>
> - Jussi
>
>
> On 21.1.2015 0.00, deco rior wrote:
>> Not sure if this helps but we have a tag called setrecursion (below for 9, we have an 8 version also)
>>
>> Then we always use the include as if it is in the root
>>
>> e.g. include(setrecursion + `lasso/doit.lasso`)
>>
>> This has actually worked very well for us.
>>
>>
>> <?lassoscript
>>
>> define setrecursion() => {
>> local(value) = Response_FilePath->split(`/`);
>> match(#value->size)=>{
>> case(2);
>> return(``);
>> case(3);
>> return(`../`);
>> case(4);
>> return(`../../`);
>> case(5);
>> return(`../../../`);
>> case(6);
>> return(`../../../../`);
>> }
>> }
>> ?>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
> the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Defining app root

Jussi Hirvi-2
I do that too, in this kind of cases.

The alternative would be to have two versions of the site structure, in
which cases the include-path problem could be solved simply by manually
editing the respective file versions - but it can be such a pain to have
duplicate (or partially duplicate) files! Besides it's ugly.

- Jussi

On 21.1.2015 17.34, deco rior wrote:

> Yep,
>
> Actually I generally link shared files via a symbolic link which works great.
>
>
>> On Jan 21, 2015, at 8:22 AM, Jussi Hirvi <[hidden email]> wrote:
>>
>> Ok, looks neat, and without testing I would say that it would work for me in most cases, except in cases where the app root is called two ways - for example, I am just developing an app where some pages are served ssl-encrypted. For those pages the app root is
>> https://secure.myserver.fi/mydomain
>> ...and for other pages
>> http://mydomain.com
>>
>> Anyway, I have a working solution now, as I explained in my previous message. The downside with that is that the actual paths (as seen in the browser source code for .css, .js paths, etc.) sometimes contain unneeded back-and-forth movement, for example /theme/../inc/../inc/my.inc. This happens with longer include chains (where file a includes file b, b includes c, etc.). But as long as the links work, I can live with that. :-)
>>
>> - Jussi

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>