This Suddenly Happed , Mindbody started to returning next class schedule date , instead of returning startdate and enddate of given class .
like this .
[StartDateTime] => 2016-05-09T17:15:00
[EndDateTime] => 2016-05-09T18:15:00
this is like for every classes i get from function GetClasses() .
The MindBody API has quite a lot of issues with regards to the GetClasses API call in my experience (I used it in a project in mid-late 2015, so perhaps things have changed since then...). Here are a list of gotchas/issues that I found when trying to get the details of a class that will hopefully assist you:
When you make a GetClasses API request, if you pass in a ClassID only, any StartDateTime and EndDateTime parameters seem to just get ignored, meaning you can't actually find a class in the future
The API seems to ignore the time part of a datetime, so when you make the call, you'll get back a list of classes held throughout the day of the datetime. The times you'll get back for each of those classes will be timezoned classes, but they'll incorrectly declare themselves to be in UTC format, rather than their actual timezone
Don't attempt to add in a specified dateTime type parameter in your API call params as that will cause the datetimes you have in those parameters to be ignored
So, basically, what I had to do was use only ever three parameters in the call:
ClientID
StartDateTime (which I made 24 hours before the class I wanted's actual start time)
EndDateTime (which I made 24 hours after the class I wanted's actual end time)
The 24 hours before and after the actual class dates were because, as I mentioned above, I couldn't trust the timezones returned for each of the classes. Anyway, this would obviously return a collection of classes rather than a single class, and from there, I'd just iterate over the collection find the class I actually wanted.
The above findings were gained as a result of copious trial and error and pouring over documentation that was frequently incorrect, if it even existed at all. Good luck.
Related
I found that there can be 5 different ways of declaring a date in VB.Net. They are:
Dim date_one As Date = #2021-3-31#: This is one of the allowed formats of date literals in VB
Dim date_two As New Date(2021,3,31) : Initializes an instance of the DateTime structure to the year, month and day
Dim date_three As DateTime : Declaring a DateTime Value to its default value
Dim date_four As New DateTime() : Calling parameterless constructor - sets to default value
Dim date_five As New DateTime(2021, 3, 31) : Supplying parameters to the constructor
My confusion /questions w.r.t to the above are the following:
A. DateTime is a structure in the system namespace. We do not use NEW keyword to declare a structure type variable. So why then in points 2,4,5 are we allowed to use the NEW keyword?
B. In point 2, we declare the type as DATE whereas in 3,4,5 we declare the type as DateTime. Infact if we compare2 & 5 then we see that they are doing exactly the same thing with the difference being tht one is declared as DATE and the other as DateTime. So my question is What is the difference between DATE and DateTime? If there is no difference why do we have two different words for the same thing?
C. Point 1 is a VB.Net language specific syntax for a date literal. This means I cant use this syntax in another .NET language. But the dates defined in points 2,3,4 and 5 make use of the DateTime structure which is in the system namespace and therefore this way of declaring or constructing dates is allowed in other .Net languages. ----> Is this understanding correct?
D. I also came across a class named DateAndTime. This belongs to the Microsoft.VisualBasic namespace and I believe that is reason this class is exclusive to VB.Net. Since it doesnt belong to the system namespace We cant import it in another .Net language --- Is this understanding correct?
E. Finally, how to decide whether to to use DATE or DateTime? Also when should we use DateAndTime Class? What advantage/limitation does each of them provide?
Would be grateful to anyone willing to help,
Regards,
Sougata
A. Class fields (variables at class level) and local variables (i.e., variables declared in methods or property getters and setters) get initialized to their default value if there is no initializer and there is no initialization code in the class constructor (for fields). So, a New is not required if you are happy with the default value.
Note that a Date (or DateTime) is a Structure and therefore a value type. Default values of value types are "real" values in contrast to reference types (Classes) having a default value of Nothing, meaning that no object is assigned to this variable. This is also called a null reference. (In fact you can assign Nothing to a value type; however, this will translate to a value like 0, False, #1/1/0001 12:00:00 AM#, etc.)
You must differentiate between declaring fields or variables and initializing them. To declare means to give them a name and a type. Initialize means assigning them value for the first time.
You can do this with two statements
Dim d As Date 'Declare
d = New Date(2021, 3, 30) 'Initialize
or use an initializer
Dim d As Date = New Date(2021, 3, 30) 'Declare and initialize
These two variants are equivalent. The first one allows you to assign a value later, the second one is more compact.
B. The .NET Framework defines primitive types and gives them a name in the System Namespace. E.g., System.String, System.Int32 or System.DateTime. Visual Basic gives many of them an alias. For the previously listed types those are String, Integer and Date. C# gives them the different aliases, string, int and has no alias for the DateTime.
The framework name and the corresponding Visual Basic (or C#) aliases are totally equivalent. System.Int32 ≡ VB Integer ≡ C# int.
C. Yes, e.g., in C# you must write new System.DateTime(...) (of course you can always import the namespace and omit the System. prefix). The Visual Basic date literal is just a short form for New Date(...) or New System.DateTime(...).
D. The DateAndTime Class is in fact a Visual Basic module. It is called class, because C# has no notion of modules as in VB and instead implements them as static classes.
The documentation says:
The DateAndTime module contains the procedures and properties used in date and time operations.
Languages in the .NET Framework have a Common Type System. Therefore, you can use a type defined in one language in all the other .NET languages. Also, the generated code is compatible, so you can share methods as well.
E. In Visual Basic I would use the aliases. It makes the code more concise.
You are using the DateAndTime automatically when you write for instance
Dim d As Date = Now
Now is declared in this module. DateAndTime does not compete with Date or DateTime, as you cannot use it to declare variables, i.e., DateAndTime is not a type.
See also:
Date Data Type (Visual Basic)
Value Types and Reference Types
Data Type Summary (Visual Basic)
Data type (Wikipedia)
A. DateTime is a structure in the system namespace. We do not use NEW keyword to declare a structure type variable. So why then in points 2,4,5 are we allowed to use the NEW keyword?
Structures may have constructors
B. In point 2, we declare the type as DATE whereas in 3,4,5 we declare the type as DateTime. Infact if we compare2 & 5 then we see that they are doing exactly the same thing with the difference being tht one is declared as DATE and the other as DateTime. So my question is What is the difference between DATE and DateTime? If there is no difference why do we have two different words for the same thing?
see https://stackoverflow.com/questions/5625795/date-instead-of-datetime
C. Point 1 is a VB.Net language specific syntax for a date literal. This means I cant use this syntax in another .NET language. But the dates defined in points 2,3,4 and 5 make use of the DateTime structure which is in the system namespace and therefore this way of declaring or constructing dates is allowed in other .Net languages. ----> Is this understanding correct?
The data type IS the same across .Net regardless of how it comes to be.
D. I also came across a class named DateAndTime. This belongs to the Microsoft.VisualBasic namespace and I believe that is reason this class is exclusive to VB.Net. Since it doesnt belong to the system namespace We cant import it in another .Net language --- Is this understanding correct?
If the .Net language allows you to import the Microsoft.VisualBasic namespace you can probably use it. Would NOT suggest it.
E. Finally, how to decide whether to to use DATE or DateTime? Also when should we use DateAndTime Class? What advantage/limitation does each of them provide?
Hmmmm.... DateAndTime does have some different date calculations that can be useful.
My preference is to use DateTime.
If all I'm interested in is the Date or Time then I reference that.
Dim d1 As Date = Date.Now
Dim d2 As DateTime = DateTime.Now
If d1 = d2 Then
Stop
End If
If d1.Date = d2.Date Then
Stop
End If
If d1.TimeOfDay = d2.TimeOfDay Then
Stop
End If
A lot of these questions can be answered by searching the documentation.
I have a superclass Appointment that is then extended to a few different types of appointments. I need to make an ArrayList of appointments of different types which I did not think would be much of a problem since they all share a common superclass - Appointment. But when I try to add one of the subclasses Daily to the ArrayList<Appointment> book = new ArrayList<Appointment>() it fails to do so.
I have:
ArrayList<Appointment> book = new ArrayList<Appointment>()
Then later on in the program (I'm passing description, day, month, and year from the method it's place in):
book.add(new Daily(description, day, month, year));
And I get the suggestion of: The method add(AppointmentBook.Appointment) in the type ArrayList is not applicable for the arguments (Daily)
Change your code from ArrayList<Appointment> to ArrayList<? extends Appointment>
I am about to start with e project that uses Struts 1.2. There is no plan to move to another framework.
I wanted to know what's the convention when handling a date in the form?
Should I create a Date variable and create a setDate(String date) method where the conversion will occur?
Create a Date variable, a setDate(Date date) and register a special converter somewhere in the chain? (don't know if it's possible)
Create a String variable, a setDate(String date) and let the conversion/validation to the validate method in the ActionForm bean?
Or another approach?
Also, if you have any advice to get up to speed with this framework, I would really appreciate it.
Before I respond to your question, let me start by saying this: People don't understand what ActionForm is or what ActionForm does
The ActionForm represents the data that the user filled in the HTML form. Struts reads in the request parameters and matches them by name with the configured ActionForm for the target Action of the submit. It is data inputted by the user, plain and simple.
Data that comes on the request is always of type java.lang.String. But people might have a form field named "age" which is an int in their Model data. Or maybe instead of "age" they have a "birthDate" which off course is java.util.Date in their Model data. So they think it is a good idea to have the type int and Date placed on the ActionForm and allow Struts to convert the Strings that arrive on request into ints and Dates.
Its a very useful conversion and you as a developer don't have to handle it, Struts does. It's a little bit of framework magic.
But this ain't freaking Harry Potter! Conversion can fail on ints and Dates. Why?
int is a primitive type and as such it must always have a value. Default initialization is with zero. When doing the binding (request parameters to ActionForm object properties) Struts sees an int type on the ActionForm and tries to convert the request String value to int.
If user inserted String "5", the field is set to 5. That's fine!
But what if user inserted "bla"? Will we get an exception thrown in our face? Nope! We get back a value of zero because conversion (silently) failed. Ups!
Dates again are an issue. Why? Because their value arrives on request as String. Their format might be something simple like "12/01/2011" which is completely useless as information. Why? Because Dates represented as Strings must go hand in hand with a Locale in order to be transformed to the correct Date instance it represents.
"12/01/2011" + Locale.US = 01 December 2011
"12/01/2011" + Locale.FRENCH = 12 January 2011
Ups!
Ok, so this was the intro! Now let's go to your question.
Should I create a Date variable and create a setDate(String date) method where the conversion will occur.
At some point you will have to send the Date back to the view and the Struts html tags will normally have to go for a getDate() which returns String. The "12/01/2011" you get on user input might be displayed as "Jan. 12, 2011 00:00:00" if the getter returns Date (Struts will do a toString() on the getter value). So you actually need the Date field with both a setter/getter of type Date and a setter/getter of type String. Use type Date in your Action class and use String for interfacing with the view tags.
Question? How do you get handle on the proper Locale value in your ActionForm?
Create a Date variable, a setDate(Date date) and register a special converter somewhere in the chain (don't know if it's possible)
It is possible. You can create and register a custom converter that might take String representations of dates and convert them to Date. If you use the ISO 8601 format I think you will be safe.
Question? Can you accommodate this into the existing application without breaking code that transforms String to dates in their own way by using all sorts of formats or Locales?
Create a String variable, a setDate(String date) and let the conversion/validation to the validate method in the actionForm bean
This won't work. The validate method is called after the parameter bindings on the ActionForm object. When you reach this point is already to late. Struts did the conversion. If you have a field of type int with value zero there is no way to know if the user actually inserted zero and conversion worked or if the user inserted "bla" and the conversion failed and you got back zero as default initialization value. If zero is a valid value for your application than you are in even bigger trouble.
So what's the convention?
There is no convention. Use the above information and apply common sense given your situation.
Ideally you should have all properties in the ActionForm as Strings so that you loose no information during the binding. But this involves manually converting the properties to the proper type in the Action class, before using them. You have full control (Struts no longer does conversions since source and destination values are of type String) but you also have a lot of boiler plate code to write to do it the proper way which at some point can become annoying.
P.S. Before I end this and go to bed (it's 01:00 AM in my Country :D) I just want to mention one thing that people often don't see. The ActionForm is not part of the model, neither should it interact directly with the model.
If you need the data from the ActionForm to be processed in the model, then map it as a one-to-one relationships with a Model DTO (data transfer object). If you don't, then you create a tight coupling between the Model and the Struts framework because your ActionForm objects are not a POJOs. Your class must extend the ActionForm class from Struts that we've been talking about. People don't do this and send the ActionForm straight to the Model. What is even worse is that they also use the validate method to perform business validations instead of basic validation such as "is required", "is value withing range" etc.
ActionForms are just a communication path between the Action (controller) and the view. Treat it as such.
I have a Model called statistics which has a value field that contains Goals (a self defined class) data
class Statistic < ActiveRecord::Base
serialize :value
end
When I try to access the goals_against (an atr_reader of the Goals class) I get
undefined method `goals_against' for #<String:0x54f8400>
The value property contains following data:
--- !ruby/object:Goals \ngoals: {}\n\ngoals_against: 1\ngoals_for: 0\nversion: 1\n
In string format according to the debugger.
It seems that rails doesn't know this data is of type Goals.
Someone knows how to solve this?
Thanks
Three things:
First, where ever your Goal class is defined, make sure it is loaded. At some point Rails stopped auto-loading stuff in the lib folder. So where ever your extra classes are located, set them in config.autoload_paths (in config/application.rb).
Second, when you declare a column as serialized, you have the option of specifying the class. This is especially useful when you are working with a custom class and you want to make sure Rails does the conversion correctly.
serialize :value, Goal
Third, when you have a column that is serialized, make sure you have enough room for it. In other words, most of the time you're going to want that column to be "text" and not "string" in your schema (otherwise your sql engine will silently truncate anything too large to fit in a string column and you'll end up saving a broken object).
Sorry for the bad question title.
Let's say that I have DateRange class that basically just consists of a start date and and end date.
My question is: How might I represent computed date ranges such as "This Week", "The Past Two Weeks", "Last Month", and "This Quarter", such that multiple clients can use these computed date ranges in a consistent way? That is, I'm going to have multiple objects of multiple classes that all need to know what "This Week" is.
I could build them into DateRange, but that doesn't seem like a good solution because more might be added or some may become obsolete over time....in fact this will happen most certainly. I could make DateRange abstract and extend it, but then I'm going to have a bunch of tiny classes. I could create some kind of static helper class that computes these dates. How might you approach this problem?
dateRange = new DateRange(RangeEnum.THISWEEK));
or
dateRange = new ThisWeek();
or
dateRange = DateHelper.getThisWeek();
or
?
To throw an additional wrench into this thing, let's say that I also need to represent a range like "the work week containing the date May 1, 2008". Upon stating that, I'm leaning towards the helper class...it just feels awkward having a big lump of goofy methods.
Why create a helper class. The common idiom used in the .NET framework would be to add Static properties to the existing class.
class DateRange
{
DateRange ourCurrentWeek = null;
public static DateRange ThisWeek
{
get
{
//create ourCurrentWeek if not yet assigned.
//test current week; is it still correct or does it need updating
return ourCurrentWeek;
}
}
}
Usage is simply:-
DateRange.ThisWeek
I would go the way with the helper class.
DateRange dr = Helper.getThisWeek();
You're right, you'll get a bunch a methods, but if you would subclass something you'll get a bunch of classes. This way you know for sure where to look.