Re: [Laszlo-dev] SOLO DHTML deployment

[Phillip George Apley]

Yes I am. I'm just catching up with this thread.


On Nov 14, 2006, at 5:33 PM, Max Carlson wrote:

I thought Phill was working on that? It's a requirement for deploying behind apache anyway...

-Max

Henry Minsky wrote:

The SOLO deploy things already puts a copy of /lps/includes into

lps/includes, which becomes a subdirectory of the application. I could

also put a copy of the LFC in there, making the whole thing easily
relocatable by having all needed files as subdirs.
It's just kind of a mess to try to munge the pathnames of the
resources if they point to directories above the app's home dir.  I'd
either have to do something gross to the javascript, or we would need

to make the compiler write out relative paths instead of absolute ones

for resource table.
On 11/14/06, Max Carlson <[EMAIL PROTECTED]> wrote:

All resource loads are relative to the page. We need a way to specify the relative URL to for global resources so developers can have several apps share resources - including the LFC. To do so, a developer will be

able to update LzApplicationRoot for app pages that share resources.

We can (and should) put this directory someplace relative to the app by

default.  'lps/embed/' for consistency perhaps?

-Max

P T Withington wrote:
> Uh, I still don't get it.
>

> You need a toe-hold to get embed.js, so that has to be someplace fixed. > The LFC can be in the same place. Then you load the app, and you can

> use the app URL to find any relative resources, right?
>

> It would be really great if you could move your SOLO deployment anywhere > in your web server without having to edit the deployment to tell it > where it is. I.e., if everything could be either at fixed point from

> your web server root or relative to the app.
>
> On 2006-11-14, at 16:37 EST, Max Carlson wrote:
>

>> Because soon, we'll need to load resources besides blank.gif for swf

>> embedding.
>>
>> -Max
>>
>> P T Withington wrote:

>>> Uh, why would you need app root to load the LFC if you don't need it

>>> to load embed.js?  We really don't want to have this if at all

>>> possible, since it makes your app depend on where it is deployed,

>>> which is an-athema of SOLO.
>>> On 2006-11-14, at 16:19 EST, Max Carlson wrote:

>>>> We will need LzApplicationRoot for other reasons, including loading >>>> a static LFC file. Please file a bug to add a client- generated 1x1

>>>> pixel  transparent image - but it's only required for IE6.
>>>>
>>>> For SOLO DHTML, you will need:
>>>> + the LFC and object code for the app
>>>> + any media resources the app needs (which include component
>>>> directories).  These should all be relative URLs.  The resource
>>>> table for the app has the list of media you need.
>>>> + lps/includes/blank.gif - Only needed for IE 6
>>>> + lps/includes/embed-dhtml.js
>>>>
>>>> -Max
>>>>
>>>> P T Withington wrote:
>>>>> I know there is a secret 1x1 .gif that is needed.

>>>>> I gave LPP-2916: 'Get rid of LzApplicationRoot' to you, because I

>>>>> think it is relevant to this task.
>>>>> On 2006-11-13, at 10:52 EST, Henry Minsky wrote:

>>>>>> Can anyone tell me what they think is required for DHTML SOLO deploy?

>>>>>> That is, what
>>>>>> auxiliary include files are needed?
>>>>>>

>>>>>> Since we serve up the LFC and the app as separate files in DHTML, the >>>>>> new SOLO wizard will at least have to write out copies of static

>>>>>> files
>>>>>> for these.
>>>>>>
>>>>>> For reference the current swf solo wizard makes
>>>>>>

>>>>>> 1) recursive copy of all files in the directory in which the app

>>>>>> resides, and also includes
>>>>>> 2) An html wrapper file (app.swf.html)
>>>>>>
>>>>>> 3) these include files
>>>>>>    filenames.add("lps/includes/embed.js");
>>>>>>     filenames.add("lps/includes/h.html");
>>>>>>     filenames.add("lps/includes/h.swf");
>>>>>>     filenames.add("lps/includes/vbembed.js");
>>>>>>

>>>>>> I will make a master list of what needs to be packaged up, and make

>>>>>> fork a version of the
>>>>>> SWF solo deployment tool for DHTML.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --Henry Minsky
>>>>>> Software Architect
>>>>>> [EMAIL PROTECTED]
>