The component in question contained a repetition which was repeating over a “row” subcomponent. I decided to make a “light” version of the row component which relied only on WOString and WOHyperlink. I refactored the “heavier” row component to extend the new, lighter one - and which will only be used inside the app.
Using ERMailUtils.instantiatePage does not create a session using the lighter version of the “row” component embedded. I think like Chuck said, something on the page was requiring a session. Tim Worman UCLA GSE&IS > On Apr 25, 2015, at 3:28 PM, A.R.E Angela <[email protected]> wrote: > > ERMailUtils.instantiatePage calls the component’s session() method which will > create a Session. > What I used to do in a distant past was to create a component with the normal > constructor and pass to this constructor a dummy WOContext. I was using this > technique to send batches of emails in the background, so not triggered by > any UI action. Below you see how I used to create such a dummy WOContext. > Hope this helps. > > Rudi Angela > > public WOContext dummyContext() > { > WOApplication app = Application.application(); > String dummyUrl = app.cgiAdaptorURL() + "/" + app.name() + > ".woa/wa/dummy"; > WORequest request = app.createRequest("GET", dummyUrl, "HTTP/1.0", > null, null, null); > WOContext context = app.createContextForRequest(request); > context._generateCompleteURLs (); > return context; > } > > >> On 24 apr. 2015, at 19:51, Chuck Hill <[email protected]> wrote: >> >> I’d be surprised if you could NOT replace some bindings to avoid session >> creation. >> >> Chuck >> >> >> On 2015-04-24, 10:24 AM, "Timothy Worman" wrote: >> >> Yeah, I see what you’re saying. That’s why I mentioned in my first that the >> component contains things that I wouldn’t want to do by hand. I’ll have to >> examine the component and remind myself of which WOComponents require a >> session. I may be able to replace bits and pieces. >> >> Tim Worman >> UCLA GSE&IS >> >> On Apr 23, 2015, at 3:56 PM, Chuck Hill <[email protected]> wrote: >> I think you are missing my point. It is not ERMailUtils.instantiatePage >> that is creating a session, it is the content of your component. The >> component you are e-mailing is using component actions, or referencing >> session.something, that is why it is creating a session (I think, this is >> what the cause usually is). You can log out a stack trace (new >> RuntimeException(“Session Created HERE”).printStackTrace() ) in the session >> constructor to see why and where they are being created. If you examine the >> component you should be able to see what needs to be changed. If you are >> mailing out component actions, the recipients are not going to be able to >> use them. >> Chuck >> On 2015-04-23, 3:47 PM, "Timothy Worman" wrote: >> Hi Chuck! >> The component that is being emailed isn’t being sent as the result of a user >> action. It is being sent as part of a quartz job. For a bunch of fetched >> EO’s, their global ID’s are passed to a method that uses >> ERMailUtils.instantiatePage to create an instance of the component for each >> EO. This all happens outside of userland. >> One thing I did was add Session.terminate in the finally block after >> try {_mailDelivery.sendEmail()} >> is called. Not sure if that is necessary. >> Tim Worman >> UCLA GSE&IS >> On Apr 23, 2015, at 3:07 PM, Chuck Hill <[email protected]> wrote: >> Hi Tim, >> It is probably because your email is using component actions instead of >> direct actions. Component actions require a session and are definitely not >> what you want in an email. For WOHyperlink, as an example, you need to bind >> directActionName instead of action. >> Chuck >> On 2015-04-23, 12:25 PM, "Timothy Worman" wrote: >> In my app I am tracking session creation - as a way to sniff out some issues >> I’ve had with some going stray. Anyhow, I am sending NSArray<EOGlobalID> to >> a background task that sends emails using ERMailDeliveryHTML. These are >> component based emails. >> Low and behold, each and every one creates a new session. Certainly I >> understand why this could/would happen depending on the contents of the >> component/page. >> I am most curiouser about what approaches decent WO folk might use to avoid >> this. This is how I’m abusing things: >> for(Object aPersonGlobalIdObject : approverIds.toArray()) { >> EOGlobalID aGlobalID = (EOGlobalID)aPersonGlobalIdObject; >> MyComponent _component = (MyComponent) >> ERMailUtils.instantiatePage("MyComponent", null); >> _component.setGlobalId(aGlobalID); >> try { >> _component.sendThisComponentToPerson(); >> } >> other stuff…. >> } >> I had thought ERMailUtils.instantiatePage was made for doing this without >> creating a session? But I must have fooled myself. >> Tim Worman >> UCLA GSE&IS >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/webobjects-dev%40olmeca.nl >> >> This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
