Re: Re: How do you show the application in the Web

>
>
> Hmm... You didn't understand me and I didn't explain well neither.
>
> For example, in the Visual Works I build a simple "Hello world"
> application, but I don't want to show it in a dialog box, even though,
> I want to show it in the Web browser like I can display
> http://localhost:8008/seaside/go/browse
> http://localhost:8008/seaside/go/counter
>
> and more, so what have I to do to get it?
>

>
>>
>>
>> Hmm... You didn't understand me and I didn't explain well neither.
>>
>> For example, in the Visual Works I build a simple "Hello world"
>> application, but I don't want to show it in a dialog box, even
>> though, I want to show it in the Web browser like I can display
>> http://localhost:8008/seaside/go/browse
>> http://localhost:8008/seaside/go/counter
>>
>> and more, so what have I to do to get it?
>>
> you want to make a new entrey point for your app ?
> so as to have
> http://localhost:8008/seaside/go/yourApp
>
>
> 2 ways
>
> 1 - override canBeRoot
> YourComponentClass class >> canBeRoot  ^true in the class side of your
> app (I think you did it), so it appear in the drop-down of root
> component when you create a new entry point from
> http://localhost:8008/seaside/go/config
>
> 2 in the class side initialization of your component, add somethink like
>
> YourComponentClass class >> initialize
> self registerAsApplication: 'yourAppName'
>
> but be careful, this method is only executed when you create the
> class. If already created, you should execute it manually.
> YourComponentClass initialize     in a workspace
>
>
> hth ;)
>
> Cédrick
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>

> Hi folks,
>
> I've recently noticed that despite having tight controls over the number
> of instantiations requested for my objects within my application, there
> is still a large number due to the session handling. This is perfectly
> understandable, but I was wondering if there is a set process for
> garbage collecting?
>
> So far I have been 'do'ing the below items just to clear things down a bit..
>
> "kill seaside processes."
> WAKom stop.
> "make sure they're dead"
> HttpService allInstances do: [:x | x stop].
> "clears cached data"
> WALRUCache allInstances do: [:x | x initialize].
> "clears context data"
> WARenderingContext allInstances do: [:x | x clearMode].
> "expires sessions"
> WASession allInstances do: [:x | x expire].
> "default garbage collection - do this several times just to be sure"
> Smalltalk garbageCollect
>
> Is there anything else I should consider?
>
> Also any pointers for use of control methods in my application would be
> most welcome.. I'm using a registry for my #children methods, and in
> callbacks where applicable (populated by lazy loaders) but I still find
> areas such as child components which render callbacks have to use new
> instantiations, which I'm not keen on. This could be resolved by passing
> the registry further down the chain, but seems overkill just to avoid
> overpopulating. Perhaps the #children method should return only
> classnames and not objects instead?

> Many thanks for any advice.
> John.
> www.pinesoft.co.uk
>
>
> Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA
>
>
>
> This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 2007/4/13, John Thornborrow <[hidden email]>:
>> Hi folks,
>>
>> I've recently noticed that despite having tight controls over the number
>> of instantiations requested for my objects within my application, there
>> is still a large number due to the session handling. This is perfectly
>> understandable, but I was wondering if there is a set process for
>> garbage collecting?
>>
>> So far I have been 'do'ing the below items just to clear things down
>> a bit..
>>
>> "kill seaside processes."
>> WAKom stop.
>> "make sure they're dead"
>> HttpService allInstances do: [:x | x stop].
>> "clears cached data"
>> WALRUCache allInstances do: [:x | x initialize].
>> "clears context data"
>> WARenderingContext allInstances do: [:x | x clearMode].
>> "expires sessions"
>> WASession allInstances do: [:x | x expire].
>> "default garbage collection - do this several times just to be sure"
>> Smalltalk garbageCollect
>>
>> Is there anything else I should consider?
>>
>> Also any pointers for use of control methods in my application would be
>> most welcome.. I'm using a registry for my #children methods, and in
>> callbacks where applicable (populated by lazy loaders) but I still find
>> areas such as child components which render callbacks have to use new
>> instantiations, which I'm not keen on. This could be resolved by passing
>> the registry further down the chain, but seems overkill just to avoid
>> overpopulating. Perhaps the #children method should return only
>> classnames and not objects instead?
>
> Squeak is object oriented so creating objects is not considered to be
> a problem.
>
> Philippe
>
>> Many thanks for any advice.
>> John.
>> www.pinesoft.co.uk
>>
>>
>> Pinesoft Computers are registered in England, Registered number:
>> 2914825. Registered office: 266-268 High Street, Waltham Cross,
>> Herts, EN8 7EA
>>
>>
>>
>> This message has been scanned for viruses by BlackSpider MailControl
>> - www.blackspider.com
>>
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>

>> Rootcomponent>>children
>>     ^Array with: SomeComponent new.
>>
>> Rootcomponent>>renderContentOn: html
>>     html render: SomeComponent new.
>
> That wont work due to different reasons:
>
> - The object you return from children is not the same object that you
> render in #renderContentOn:
>
> - With every request you create a new instance of SomeComponent and
> loose all the existing state. You should never need to initialize
> components in rendering code.
>
>> Now, that is a *very* simple example - but it does demonstrate what I am
>> referring to - there are now two instances of SomeComponent, when only
>> one is needed. This will be resolved by a lazy loader, but for more
>> complex examples it is not easy.
>
> This is standard:
>
> Rootcomponent>>initialize
>     super initialize.
>     some := SomeComponent new.
>
> Rootcomponent>>children
>     ^Array with: some
>
> Rootcomponent>>renderContentOn: html
>     html render: some
>
>> I am still learning with Seaside, but so far I can see that the
>> #children are then processed with #childrenDo: but I still ask "Why?"
>> Why must they have this processing here, and not at rendering?
>
> Because Seaside is stateful. It needs the children information to
> process callbacks, to render the <head>, to enable REST-ful URLs and
> probably other things ...
>
> Lukas
>

> > Both components have an effect on the html root object (both over ride
> > #updateRoot:) and have differing values. So far "it's working" but I am
> > not sure if this is an acceptable process for it? Does the html root
> > object make changes to the root attributes (or other items) according to
> > both components, regardless of which component is rendered?
>
> It is ok to return too many components from #children, it is just
> required that you return all component instances that might be
> rendered. However, you can also do something like:
>
> Root>>children
>    ^(someExpression)
>       ifTrue: [Array with: componentOne]
>       ifFalse: [Array with: componentTwo]

> Cheers,
> Lukas
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>