Is there any way to access the information on a atribute text inside a block object ? (Autolisp) - autolisp

Basically, I want a function that goes through the drawing and searchs for attribute definition text, I can do it normally, but if I make a block with said attribute text the function can't find them anymore. I don't know if it's even possible to do it.

To achieve your task, you'll want to look at the value (Textstring property) of the attribute references, as opposed to the attribute definitions.
Attribute references are held by the block reference and their values may vary between multiple references of the same block, whereas attribute definitions reside within the single block definition (i.e. the blueprint for the block) and hold an optional default value.
The attribute references may be accessed either through Vanilla AutoLISP using the entnext function to iterate over the attribute reference subentities which follow a block reference entity in the drawing database (example), or through Visual LISP by invoking the ActiveX getattributes method (example).
My existing Count Attribute Values program should provide some insight into how to accomplish this - you'll only need to differentiate the references by block name in addition to attribute value.

Related

What to name a class with few properties and no methods whose instances get passed around a lot?

I have several small classes that are similar in that they only possess a few properties and no methods, and their instances often get passed around and put into arrays and what not. Is there a naming convention for such a class? At first I was naming them xxxObject, but in OOP that's not really what an object is. Then I considered naming them xxxHelper, but helper seems to indicate methods. What should I add on to the end of this type of class's name?
I would not make these classes at all, it looks like you're using some kind of a global enum or a dictionary.
Enum from C would indicate a key and an integer value.
Dictionary from Python would indicate key and value, value doesn't have to be a specific type.
I would probably use XXDictionary.

How do you create a Collection of GenuineVariableDescriptors?

I'm trying to implement my own MoveListFactory and don't know how to access / create the variable descriptors for the move I want to instantiate. The createMoveList method (from the MoveListFactory interface) takes a single argument of an instance of my Solution class. From this I can access all the planning variables that I need to create a ChainSwapMove. What I'm unsure about is how to create the first argument that the ChainSwapMove constructor requires (e.g. the Collection<GenuineVariableDescriptor>). The example in the documentation doesn't shed any light on this process since the custom move used in the NQueens example doesn't require this Collection of GenuineVariableDescriptors. I've not come across any examples of how someone can access these from only the information contained in a Solution object.
Anything ending with *Descriptor is very internal API, not the kind of classes I want users to be using. The docs presume you build your own move (which is difficult indeed to build a valid move on chained variables that leaves the chain in a valid state).
That being said, here's a clue: InnerScoreDirector.getSolutionDescriptor().getEntityDescripor(MyCustomer.class).getVariableDescriptor("myPreviousStandstill") ...

MVC : How to use database to drive validation attributes, or ALTERNATIVES?

In summary, I'm trying to create instance-specific data-annotation attributes at runtime, based on database fields. What I have now works fine for creating the initial model, but falls over when the model is posted-back and the server-validation happens.
(I have the same input model being used in a collection within a viewmodel, but different validation must be applied to each instance in the collection....for example the first occurrence of the input may be restricted to a range of 1-100 but the next occurrence of the same model, prompted for on the same input page, would be a range of 1000-2000. Another may be a date, or a string that has to be 6 characters long.......)
I'll explain what I've done and where my issues are:
I've inherited DataAnnotationsModelMetadataProvider and provided my own implementation of GetMetadataForProperty (This doesn't have any bearing on the validation problem....yet)
I've inherited DataAnnotationsModelValidatorProvider and provided a facade implementation of GetValidators. What I want to do here is create new attributes based on my database-records and then pass those attributes through to the base implementation so the Validators are created accordingly.
However...... GetValidators is called at a PROPERTY level....When it is called with a propertyname that I want to apply validators to, I need to find the applicable DB record for this propertyname so I can find out what attributes I need to create....BUT...I can't get the DB record's key from just a propertyname of the value field.....In fact, the DB key is in the parent model.....So how do I get hold of it?!
I've tried using a static variable (YUK) and storing the key during a call for one property, and retrieving it during another call for my value field property....But because the model is serialised one-way and deserialised the opposite way I end up with my key being out-of-sync with my required attributes.
To add a slight complication I'm also using a custom model binder. I've overridden CreateModel as advised elsewhere on here, but I can't find a way of attaching metadata or additionalvalues to a PROPERTY of my output model....Only to the model itself....but how do I get at MODEL metadata/additionalvalues inside the GetValidators call for a PROPERTY ?
So....My question is twofold.....
1) Can anyone help me get my database-key from my custom-Model-binder to my GetValidators method on my ValidationProvider? Or maybe using my custom Metadata provider?
2) Is there a different, simpler, way of creating validators at runtime based on database records?
I think you are making this far more complicated than it needs to be. You just need to make whatever your validation criteria selectors are part of your view model. They don't necessarily have to be displayed (they can be stored in hiddens if they need to be kept for postback purposes).
Then you can use something like FluentValidation to create rules that say
RuleFor(model => model.myprop)
.When(model => model.criteria == whatever)
.GreaterThan(100)
.LessThan(1000);
Where criteria is whatever value you use to select when your property has to be in a certain range.
So that would mean you build your view model to include the criteria that is used for validation rule selection.
I'd asked this on the FluentValidation forums also and the lack of answers here as well as the advice against using Fluent from there led me to find my own solution (I understand this almost certainly means I'm doing something really bad / unusual / unnecessary!)
What I've ended up doing is assigning my controller static variable in my Custom Model Binder's CreateModel method, where I have access to the entire client model, rather than trying to do it through a custom MetaDataProvider. This seems to work just fine and gets me towards v1 of my app.
I'm not really happy with this solution though so will look to refactor this whole area in the coming months so would still appreciate any other comments / ideas people have about how to implement dynamic validation in a generic way.
I know this is an old question, but I am answering this so that many others can be benefited from this.
Please see the below article where they are loading the attributes from an xml
Loading C# MVC .NET Data Annotation Attributes From XML, Form Validation
I think you can follow the same approach and instead of reading from xml you can read from database and add these rules dynamically based on the model data type
You can refer the below approach also
DataAnnotations dynamically attaching attributes

Is there a way to change default values of a core data attribute

I would like to change the default value of some of the attributes in my core data model dynamically.
For instance, my app deals with real estate investment, and I have an attribute pertaining to interest rate (the type Float). If the user enters an interest rate of 3.5% (float value would be 3.5) for a particular property they are analyzing, I would like the value for the next property they analyze to automatically populate with 3.5.
Is there a way to accomplish this without subclassing NSManagedObject?
Good question - by default, managed objects are initialized with the default values given in the managed object model. But like you say, sometimes you might want a dynamic default value (the example Apple use in their own documentation is using the current date/time as a default value).
Unfortunately I don't believe there's a way to do this without subclassing NSManagedObject. There's an Apple recommended way to do this - rather than overriding the init method (not recommended), you instead use the awakeFromInsert method, which is called when the object in question is first inserted into the managed object context.
Here's what Apple say from their own docs:
awakeFromInsert:
You typically use this method to initialize special default property values. This method is invoked only once in the object's lifetime.
If you want to set attribute values in an implementation of this method, you should typically use primitive accessor methods (either setPrimitiveValue:forKey: or—better—the appropriate custom primitive accessors). This ensures that the new values are treated as baseline values rather than being recorded as undoable changes for the properties in question.
So to answer your original question - I can't think of a way to do this without subclassing NSManagedObject, and subclassing is the officially recommended approach for handling dynamic default values.

flexjson and versioning : how accommodating change is flexjson?

I'm considering using flexjson to serialise my business objects to a file in an android application, simply using JSONSerializer().deepSerialise(myObject) and JSONDeserializer().deserialise(jsonString) with all the default transformers and object factories.
I'm hoping that once the application is released any changes to the business model should be accommodated by writing flexjsons transformers and object factories in the new release to maintain compatibility with previous versions.
What I'm not sure about is what changes the default transformers and object factories can cope with.
i.e if I add a field to a class and deserialise from an old version without the field into the new class will it fail or will the new field be null or 0 (if a number). Same question if I remove a field, what happens.
In standard java serialisation this is all documented here..
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html
But I cant find the equivalent information for flexjson, that deals explicitly with the issues surrounding versioning of objects, Is there any?
Cheers,
Phil.
Flexjson will look at the JSON first to find any fields it contains, and then looks for those fields on the Object you are deserializing into. So adding new fields to an object will not cause the deserialization process to fail. The new field will just not be populated from the JSON object (ie it will retain the value(s) set in the constructor or the initialization values).
If you remove a field from an object in the future Flexjson will simply not deserialize that value into the object because it won't find a setter for it.
So you can think about the getter/setter functions as a declaration on the JSON of what you want out of it. You aren't required to serialize/deserialize all values from the JSON object.
The only part that gets really tricky is if you rename fields, or change types on a field. Renaming field can be handled by keeping the older setter around and internally setting the new field in that older setter. You can mark it private or protected to hide it from the outside and Flexjson will still use it. If you change the type it is much more tricky. One option is to keep the older setter with the prior type around (like setFoo(String) and setFoo(List)) and adapt to the new type. The other option is to write your ObjectFactory to translate between to the two potential types. This of course is the hardest to do. The last option is don't do this without changing the name of the field, and use one of the other methods to translate.