TicketFactory

[Colin Foley]

As it stands, the TicketFactory is highly dependent upon a rigid Performance structure.  This model doesn't fit with the rest of ATHENA's flexibility.  While solely passing a Performance ID is convenient, ATHENA Clients may not even implement a Performance model. 

I propose that the TicketFactory take a template for a Ticket and a quantity.  Essentially, one tells the Factory what they want produced and how much of it they want produced.  This leaves the ATHENA implementation open to the Client while providing them a means to create Tickets en masse.  While this takes away the convenience of the Performance ID, it frees ATHENA Clients to use the system however they want.  The Client can easily determine how many tickets it needs, because the Client developers are well versed in their own ATHENA implementation.  Ticket quantity calculation should be done on the Client-side.

Here is a JSON example:

{

• "quantity": 25,
• "template": {
  • "eventId": 37720,
  • "venueId": 27720,
  • "performanceId": 88080,
  • "price": 12.95
  }

}

--

Colin Foley

Web Application Developer

Accella LLC

colin...@accella.net | 610.570.6514 | www.accella.net

[Gary Moore]

This is a great idea and I'm certainly open to getting a better bulk-ticket creation solution.

Colin, your method really takes ticketfactory out of the equation. In essence, you're proposing a method for bulk ticket creation.

Is there really a need for ticketfactory then? What ticketfactory gets you is that it will look up sections and capacities of your performance as long as you've configured that sort of thing. If you haven't we should have some way for the user client to say "I need 25 tickets like this..."

Gary

----- Original Message -----
From: "Colin Foley" <colin...@accella.net>
To: athena-t...@googlegroups.com
Sent: Thursday, April 7, 2011 10:09:49 AM
Subject: [athena-tix-devel] TicketFactory

As it stands, the TicketFactory is highly dependent upon a rigid Performance structure. This model doesn't fit with the rest of ATHENA's flexibility. While solely passing a Performance ID is convenient, ATHENA Clients may not even implement a Performance model.

I propose that the TicketFactory take a template for a Ticket and a quantity. Essentially, one tells the Factory what they want produced and how much of it they want produced. This leaves the ATHENA implementation open to the Client while providing them a means to create Tickets en masse. While this takes away the convenience of the Performance ID, it frees ATHENA Clients to use the system however they want. The Client can easily determine how many tickets it needs, because the Client developers are well versed in their own ATHENA implementation. Ticket quantity calculation should be done on the Client-side.

Here is a JSON example:

{

• "quantity" : 25 ,
• "template" : {
• "eventId" : 37720 ,
• "venueId" : 27720 ,
• "performanceId" : 88080 ,
• "price" : 12.95

}

}

--
Colin Foley
Web Application Developer
Accella LLC
colin...@accella.net | 610.570.6514 | www.accella.net

--
Visit: http://athena.fracturedatlas.org/tix
Fork: http://github.com/fracturedatlas
Chat: ##athena on Freenode

You received this email because you are subscribed to the "ATHENA Tix Developers" group on Google Groups.

To post, email: athena-t...@googlegroups.com
To unsubscribe, email: athena-tix-dev...@googlegroups.com
For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en

--
Gary Moore | gary....@fracturedatlas.org | @gsmoore
Fork us on Github: http://github.com/fracturedatlas/
Join us on IRC: ##athena on irc.freenode.net

[Micah Frost]

Currently, we're relying on the generation of the ID within ATHENA. This means that Colin's method would work, as our template could just specify every other property needed.

An alternative would be to allow ATHENA to accept an array of objects when POSTing them for creation. This leaves it up to the client to generate the appropriate body at the cost of increased network traffic. The main win here is that ATHENA remains decoupled from the properties used by any given implementation. It might look something like

POST /tix/tickets
[
{
"price": 50,
"performanceId": 1,
"eventId": 1,
"etc": …
},
{
"price": 50,
"performanceId": 1,
"eventId": 1,
"etc": …
}
]

The last option would be to find middle ground. If we want to great N identical tickets, then a quantity N can be included in the body, and ATHENA will handle it accordingly. If each ticket has more complex properties, then let the client pack them into an array.

Micah

[Gary Moore]

Colin, All,

Drafted a README on the bulk helper which will allow you guys to post a JSON array of tickets for creation.

https://github.com/fracturedatlas/ATHENA/tree/master/helpers/bulk

I'll CC this to Unfuddle

[Adam Huttler]

Is the Bulk helper specific to Tix, or is it a generic helper that could be used for, e.g., People as well?

---

--
Visit: http://athena.fracturedatlas.org

[Gary Moore]

We'll ship with it mated to tix, but the code itself is type agnostic and can be used for all Athena types.

----- Original Message -----
From: "Adam Huttler" <adam.h...@fracturedatlas.org>
To: athena-t...@googlegroups.com
Sent: Tuesday, May 3, 2011 3:48:38 PM
Subject: Re: [athena-tix-devel] TicketFactory

Is the Bulk helper specific to Tix, or is it a generic helper that could be used for, e.g., People as well?